一些不曾注意的代码规范

不经历这一遭，永远不会明白为啥要遵循这些规范

命名规范

基础的驼峰或者其他，相信不用多说，重点在于，平时以为没必要的

xml中属性顺序

在第一个版本开发的时候，往往不会注意这些，写的顺序会比较混乱，毕竟复制黏贴不少，甚至有些width和height还有id放到最下面去了。
但是重构的时候，或者说第二个版本开发的时候，想要快速理解代码，这里就增加了很多难度，有时候要找是否有居中，间距多少，要查看半天
so, 这里建议，按顺序写，首先写id，然后宽高，然后相对位置，然后间距，再然后其他

xml中每个控件的用途注释

这里有利于理解代码，特别是对于英语不好的同学，每次要去看id命名，然后脑子里要把英文转为中文，如果有个地方相似id有几个，那看得更加头疼。

文件名

尽量以model+function的形式命名，或者其他，而且一旦约定，最好就要遵循，这样看起来会非常的舒服

资源名

在第一版开发的时候，为了偷懒，经常在xml中直接引用公用的资源，例如default_blug_color,可是后续改版中，一旦项目风格改变，那么，就只能在对应的xml中去修改，所以建议：在color中将对应需要使用的颜色声明出来，然后引用default_blug_color，这样，便于查看和修改

正式改版开发的约定

命名

有时候你不能更改原文件，一是为了方便对照，二是不引起其他地方报错，比如有写activity需要intent各种传值，接受值，如果，没有做好容错处理，很容易nullPointException

建议约定，新版本的都命名为在文件末尾添加一标识例如“_new”或者“_temp”
而且，在变量中尽量不要使用包含以上的命名，这样就可以写一个脚本，通过遍历的方式来修改，而不是手动修改，but，资源文件中，有可能存在_new
的变量，所以，在写这个脚本的时候，务必排除这些有可能有类似变量的文件，至于修改之后发生的错误，运行一遍，一目了然，再慢慢修改，我认为这样比重复劳动n次所造成的劳累要小很多。(当然，不同类型的人，不一样)
不过，在这之前，如果代码结构有变化，建议先把原有的文件移动到对应模块下，这样新建的文件和旧的文件，会排列在一起，便于查看

功能模块

最好是边界清晰，方便复用

暂时想到这么多，先这样吧