Repository navigation
4点建议 #2
Description
Activity
收到小伙子，多谢建议
-
layout_marginStart、layout_marginHorizontal在 style 中书写时存在什么使用局限？ -
关于非公开成员变量使用小 m 开头，其实这个问题在行业内颇有争议，但是从谷歌的源码、Support 库源码来分析，他们还是使用的这种方式，所以我个人建议使用这种方式来做，因为这样的解释会有一定的公信力。如果出现 set 和 get 方法时，如果用 public 会导致一个问题，那就是变量变得不可控，例如我只想让外层 get 该值、但实际是调用者却可以 set 该值。
-
资源 ID 命名是一定要按照模块来命名，当然也要考虑一些特殊情况，例如一些共用的 String，例如
确定取消这种，其实文档中都有注明命名方式，你可以仔细观看String ID 命名规范，由于今天鸿洋转载的代码规范是旧版本的，所以他那篇文章中并没有注明该项。 -
当规范需要新增或者修改时，请参考 代码规范原则。
-
小伙子，还有别的建议或者问题不，没有的话我就关闭 issue 了
算了说了你也听不进，还是直接关了好
小伙子，只要你是对的，代码规范文档也会跟着改，但关键是你连我都说服不了，别人问起来时我又该怎么说服他？
Reacted by ad5666, hai, MarkGosling and FanXH123Reacted by LD小伙子，只要你是对的，代码规范文档也会跟着改，但关键是你连我都说服不了，别人问起来时我又该怎么说服他？
我想第一条建议说的是这种情况👀
@SaltedFish-Extreme 小伙子，我试了一下，你在 style.xml 这样写肯定会报这个提示，但是你在 layout.xml 中写就不会有，原理是因为 Studio 在编译时做了一些优化，它会自动帮你把 paddingHorizontal 转成 paddingStart 和 paddingEnd。
@SaltedFish-Extreme 小伙子，我试了一下，你在 style.xml 这样写肯定会报这个提示，但是你在 layout.xml 中写就不会有，原理是因为 Studio 在编译时做了一些优化，它会自动帮你把 paddingHorizontal 转成 paddingStart 和 paddingEnd。
我看如果编译版本高的话在安卓8以上才允许在style文件中这样写，这样的话，为了兼容低版本以及复用属性，在style文件中使用margin和padding时候还是用上下左右的好
关于非公开成员变量使用小 m 开头的问题，这个应该是AOSP的历史遗漏问题https://source.android.google.cn/source/code-style?hl=zh-cn#follow-field-naming-conventions
google现在的JavaStyleGuide是不推荐这样的命名的https://google.github.io/styleguide/javaguide.html#s5.1-identifier-names@altair441n 小伙子，AOSP 是 Android Open Source Project 的意思，谷歌在 AOSP 规范文档上面还是写着 非公开成员变量使用小 m 开头，而 Java 规范文档上面却写着不推荐，本身这个就存在巨大争议，但是谷歌的源码都是 AOSP 的风格来走的，所以代码规范文档还是得暂时按照 AOSP 的风格来走。
@altair441n 小伙子，AOSP 是 Android Open Source Project 的意思，谷歌在 AOSP 规范文档上面还是写着 非公开成员变量使用小 m 开头，而 Java 规范文档上面却写着不推荐，本身这个就存在巨大争议，但是谷歌的源码都是 AOSP 的风格来走的，所以代码规范文档还是得暂时按照 AOSP 的风格来走。
我知道AOSP的意思，我的意思是AOSP代码规范是谷歌早期推荐的，现在提交到AOSP的Pull Request为了保持代码的一致性也被要求符合AOSP的代码规范，这是历史遗留问题，谷歌现在好像已经不推荐成员变量前加m或s了。
算了说了你也听不进，还是直接关了好
真实
Reacted by LD第二条后半段，楼主的意思应该是
public class Test {
private String s;
public void setS();
public String getS();
}
写成
public class Test {
public String s;
}Reacted by Cpf-666
1、layout_marginStart、layout_marginHorizontal在style中书写时存在使用局限。
2、关于全局变量命名不提倡使用mInstrument这种形式，模型使用如果同时出现set、get方法时，使用public更便捷。理由参考《代码整洁之道》。
3、资源ID命名上不建议带上模块名称（layout除外）。存在重复使用的string，带有模块名称并不合适。建议使用资源的属性功能去命名，这样虽然可能损失了某种程度上的美观，但是总体来说，提升代码开发效率，不必花时间去翻找重复的资源。
4、部分规范不必完全遵守，应根据实际出发。