4点建议

[Deep-In-It]

1、layout_marginStart、layout_marginHorizontal在style中书写时存在使用局限。 2、关于全局变量命名不提倡使用mInstrument这种形式，模型使用如果同时出现set、get方法时，使用public更便捷。理由参考《代码整洁之道》。 3、资源ID命名上不建议带上模块名称（layout除外）。存在重复使用的string，带有模块名称并不合适。建议使用资源的属性功能去命名，这样虽然可能损失了某种程度上的美观，但是总体来说，提升代码开发效率，不必花时间去翻找重复的资源。 4、部分规范不必完全遵守，应根据实际出发。

[getActivity]

收到小伙子，多谢建议

[getActivity]

1. layout_marginStart、layout_marginHorizontal 在 style 中书写时存在什么使用局限？

2. 关于非公开成员变量使用小 m 开头，其实这个问题在行业内颇有争议，但是从谷歌的源码、Support 库源码来分析，他们还是使用的这种方式，所以我个人建议使用这种方式来做，因为这样的解释会有一定的公信力。如果出现 set 和 get 方法时，如果用 public 会导致一个问题，那就是变量变得不可控，例如我只想让外层 get 该值、但实际是调用者却可以 set 该值。

3. 资源 ID 命名是一定要按照模块来命名，当然也要考虑一些特殊情况，例如一些共用的 String，例如 确定取消 这种，其实文档中都有注明命名方式，你可以仔细观看String ID 命名规范，由于今天鸿洋转载的代码规范是旧版本的，所以他那篇文章中并没有注明该项。

4. 当规范需要新增或者修改时，请参考 代码规范原则。

[getActivity]

小伙子，还有别的建议或者问题不，没有的话我就关闭 issue 了

[Deep-In-It]

算了说了你也听不进，还是直接关了好

[getActivity]

小伙子，只要你是对的，代码规范文档也会跟着改，但关键是你连我都说服不了，别人问起来时我又该怎么说服他？

[SaltedFish-Extreme]

小伙子，只要你是对的，代码规范文档也会跟着改，但关键是你连我都说服不了，别人问起来时我又该怎么说服他？

我想第一条建议说的是这种情况👀

[getActivity]

@SaltedFish-Extreme 小伙子，我试了一下，你在 style.xml 这样写肯定会报这个提示，但是你在 layout.xml 中写就不会有，原理是因为 Studio 在编译时做了一些优化，它会自动帮你把 paddingHorizontal 转成 paddingStart 和 paddingEnd。

[SaltedFish-Extreme]

@SaltedFish-Extreme 小伙子，我试了一下，你在 style.xml 这样写肯定会报这个提示，但是你在 layout.xml 中写就不会有，原理是因为 Studio 在编译时做了一些优化，它会自动帮你把 paddingHorizontal 转成 paddingStart 和 paddingEnd。

我看如果编译版本高的话在安卓8以上才允许在style文件中这样写，这样的话，为了兼容低版本以及复用属性，在style文件中使用margin和padding时候还是用上下左右的好

[altair441n]

关于非公开成员变量使用小 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

[getActivity]

@altair441n 小伙子，AOSP 是 Android Open Source Project 的意思，谷歌在 AOSP 规范文档上面还是写着 非公开成员变量使用小 m 开头，而 Java 规范文档上面却写着不推荐，本身这个就存在巨大争议，但是谷歌的源码都是 AOSP 的风格来走的，所以代码规范文档还是得暂时按照 AOSP 的风格来走。

[altair441n]

@altair441n 小伙子，AOSP 是 Android Open Source Project 的意思，谷歌在 AOSP 规范文档上面还是写着 非公开成员变量使用小 m 开头，而 Java 规范文档上面却写着不推荐，本身这个就存在巨大争议，但是谷歌的源码都是 AOSP 的风格来走的，所以代码规范文档还是得暂时按照 AOSP 的风格来走。

我知道AOSP的意思，我的意思是AOSP代码规范是谷歌早期推荐的，现在提交到AOSP的Pull Request为了保持代码的一致性也被要求符合AOSP的代码规范，这是历史遗留问题，谷歌现在好像已经不推荐成员变量前加m或s了。

[protectedMan]

算了说了你也听不进，还是直接关了好

真实

[gaoyl87]

第二条后半段，楼主的意思应该是 public class Test { private String s; public void setS(); public String getS(); } 写成 public class Test { public String s; }