统一格式化

多人合作开发项目时，统一的代码格式可以避免代码提交、合并时很多不必要的冲突。

代码格式风格要使用IDE自带的默认格式化风格。禁止自定义修改风格，禁止使用第三方定义的风格。

Android Studio，Preference窗口中的代码风格设置界面

使用统一的默认风格原因有如下几点：

不需要手动修改，所以不需要专门去关注，避免新伙伴加入时导致风格不一致问题
默认风格本身已经够用，可以说是广为人接收的风格了，不需要也没必要去修改。

有条件的情况下当然是对项目进行一次性的全局格式化更好。但是考虑到项目会有多个分支，也会有多个开发者的本地变化，这一点在实际上很难操作，因为会引起大量的冲突问题。

次一级的方案就是在开发过程中进行格式化，这样由点及面逐步的进行统一格式覆盖，最终达到格式一致的目标。提交代码时，借助IDE的功能进行自动格式化，可以避免开发者在提交代码前忘记格式化。

Android Studio提交代码时的代码优化选项

建议同时选中Reformat Code 与Optimize imports，进行自动格式化与整理import。
不建议开启Rearrange code开关 - 这一功能会将代码进行排序，而且新的顺序可能并不是我们想要的；并且有可能会出现两次运行结果排序不一致的情况，不利于代码格式一致性。
其他开关可以根据需要决定是否开启。

关注并解决代码中的警告(warning)

程序员向来不关注警告，因此吸烟的有，开车坠崖的也有~~
虽然是个笑话，但是说明了两个问题:

警告出现的很频繁，以至于习以为常了
警告没有提供有用信息 - 至少程序员是这样认为的

通常情况下确实是这样的：

定义的方法、变量没有使用到

没有用到的变量定义
多余的变量初始化代码

多余的变量初始化
多余的条件判断

多余的条件判断
空的语句

空的条件语句

以上警告问题在代码中经常会遇到，其实质上也只是小建议而已，是否修改并不影响程序的正确性，而且编译时还有可能被自动优化解决掉，并不会影响实质的运行效率。

然而事实上并不都是这样的，一些情况下，warning会提示出真正的错误的：

经常遇到的Handler警告，提示开发者如何开发可以避免内存泄露问题

非静态handler警告
Map<Interger, V> 警告，提示开发者使用更节省内存的数据结构

最新IDE已经不对该问题进行提示了，可能是Android内存越来越大不需要节省了。

还有warning能够直接爆出代码编程错误

红色警告提示字符串不符合format格式

清理warning对于开发者来说有百利而无一害。一个较大的代码文件可能会有几十几百个的警告信息，其中可能就潜藏着几个bug。如果代码中本身没有几个警告，那新出现的警告就会变成黑夜中的明灯，照亮bug的位置。

除了使用IDE自带的lint工具查看警告，还可以使用findBugs插件对代码进行静态排查。通过优化解决代码中的问题，能够提高代码质量，发现潜藏问题，何乐而不为？

解决警告的目的是为了提高代码质量，而不是单纯的消除黄色提示。所以关闭警告提示开关、使用SuppressWarnings注解等自欺欺人的做法在一般情况下就不要用了。

及时删除无用代码

软件开发的过程像一颗不断增长的大树，不断长出新的枝叶，也不断有老的枝叶枯萎。
在不断的业务迭代下，很多久远的代码逻辑已经不可达、资源文件也已经过时不再使用。这种情况下应该快刀斩乱麻，将古老的无用代码删除，避免污染当前的代码库。有各种版本管理工具，不用怕代码彻底丢失问题。而且根据经验，已删除的代码再次被恢复的几率微乎其微，遇到这种情况，多半是产品策略问题，需要找一找开发流程上是否出了什么问题。

删除代码与资源时，一定注意不要影响到现有逻辑。

合理添加注释

很多人不喜欢在代码中添加注释。大家都知道单纯的读代码有时候不容易理解，好的代码都是有注释的，注释有助于快速理解代码内容。

多余型注释

没有注释的代码被人诟病，所以很多人开始有意识的添加注释。但是有些情况下，注释内容让人哭笑不得：

/**
 * 上下文
 */
private Context mContext;

想说的太多，但是一句也不想在这里写出来，算了~~~

翻译型注释

还有的注释像下面这样：

/**
 * 重要信息
 */
private String importantInfo;

“重要信息”直接把变量名称翻译了一下，但是信息内容是什么，为什么重要，这个数据怎么来的怎么使用，一概没有。
注意，我们要的是注释，不是翻译！ 做翻译查个单词，有很多工具可用，不需要专门写在注释里面！

错误型注释

无论如何，上面两种代码上是有注释的，而且不能说是错误的注释(虽然没有什么用，但也不能说他是错的啊)。有的注释随代码一起添加，但在后续的开发过程中，代码已经变化了，但是注释却没有更新，就导致注释内容成了错误的信息。这种注释对于开发者来说更是致命的，不如没有。

所以当代码发生变化的时候，如果没有时间更新注释内容，建议直接上手将其删除，避免导致注释错误。

如何添加注释

添加注释要抓住重点，同时要考虑到注释的读者对象。

作为普通的业务代码，介绍一下当前的类、方法大概是在做什么就可以了，或者可以介绍一下(特殊的)业务背景之类的，内部逻辑或背景较复杂的代码需要添加一些说明性文档。但是详尽的多余型、翻译型注释就不要添加了，一起工作的都是水平相当的同事，谁也不傻。

作为SDK类型的代码，主要需要介绍类的职责、方法的输入输出，必要时可以介绍使用方法。这方面可以就近参考一下Android SDK源码上的注释，观察他在哪些位置添加了详尽的注释，哪些位置又没有添加任何注释。(Android SDK面向的是广大水平不一的开发者，其对外接口部分提供了详实的说明性注释，更有大量的用法说明；而不开放的变量、方法尤其是私有方法，则很少添加注释甚至没有注释。)