开发入门——代码规范

    此文主要梳理一下 Android 开发中涉及的代码规范问题，无论你是编码老鸟还是入门菜鸟，甚至是还没入门的菜蛋，都不可忽略代码规范。

代码规范的作用
1、有助于提高思路清晰程度；
2、有利于提高团队协作效率；
3、减少 BUG，减少 BUG，减少 BUG，重要事情说三遍……；
4、有助于提高程序员自身的软实力；
5、降低维护成本；
6、不说了，想想你接手过的烂代码……（新手忽略，但是成为老手之前，肯定会有次经历）。

代码规范涉及什么内容？
1、命名规范
2、注释规范
3、语句格式规范(换行、空格、空行规范)
4、文件编码格式规范
5、Log 规范
6、层次规范(分包、分类、分方法)

命名规范
关于命名规范，所提及的“必须”、“务必”等词，为强烈建议的标准命名规范，并不是说其他的格式就不支持，只是不建议。
目前 Android 开发中主要涉及的命名问题，主要体现包名、类名（含接口、枚举等）、方法名、变量名、常量名、布局文件命名、资源文件命名等方面，具体要求：
包名：统一小写，建议每个点分隔符之间有且仅有一个自然语义的英语单词(阿里是强制要求)，且仅使用单数形式，例：com.tencent.mobileqq.ui.acitivity；
类名：必须使用UpperCamelCase格式，即首字母大写的驼峰命名。抽象类命名使用 Abstract 或 Base 开头；异常类命名使用 Exception 结尾；测试类 命名以它要测试的类的名称开始，以 Test 结尾。例：BaseActivity、ImageView……
方法名、变量名：必须使用 lowerCamelCase 格式，即首字母小写的驼峰命名，例：setText(…)、currentValue……
常量名：所有字母大写，单词间用下划线隔开。例：MAX_TRANS_AMOUNT、URL_HOME_PAGE……
布局文件名：所有字母小写，单词间用下划线隔开，以布局功能字符开头。例：activity_xxx_yyy_zzz、fragment_xxx_yy_zz、item_xx_yy_zz ……
资源文件名：所有字母小写，单词间用下划线隔开，以资源文件分类单词开头或结尾，例：drawable_selector_xxx_yyy_zzz、menu_xxx_yyy_zzz ……
强烈建议：
1、所有命名，均以字母开头；
2、所有命名，避免使用汉语拼音；
3、避免随意缩写单词，要么使用标准的缩写，要么使用完整的单词，可以适当放宽名字长度，重点在于表达清楚(要让其他人见名知义，而不是“我一看就知道呀”)。

注释规范
行注释：// 双斜杠后的内容为注释内容，建议行注释放在代码上一行，或者代码行，不建议把行注释放在代码行下面。行注释力求言简意赅。
块注释：/* 斜杠星与星斜杠之间的内容为块注释内容 */ ，块注释主要用于大段落注释或代码行行内注释（斜杠星之前和星斜杠之后的代码都是有效代码）。
文档注释：/* 斜杠星星与星斜杠之间的内容是文档注释 /，文档注释主要用于方法 (method) 的注释，可以标记方法的功能、名称、参数、返回值、异常抛出等信息，最重要的功能是可以快速生成 API 文档，便于其他开发者快速了解相关方法的具体信息。
强烈建议：给每个新写的类、方法写上文档注释(内部方法或命名明确的可以酌情忽略)，给复杂的逻辑写上行注释或块注释，避免将来重新看代码的时候想不起来。
开心一刻：某前辈的代码中注释“写这段代码的时候，只有我和上帝知道它是什么，现在只有上帝知道”(原文为英文，如需，请自行搜索)。

语句格式规范
大括号{}：如果大括号内为空，写成{}即可，不需要换行；如果是非空代码块则需：
1） 左大括号前不换行；
2） 左大括号后换行；
3） 右大括号前换行；
4） 右大括号后还有 else 等代码则不换行，表示终止右大括号后必须换行。
括号()： 左括号和后一个字符之间不出现空格，右括号和前一个字符之间也不出现空格；
if/for/while/switch/do 等保留字与左右括号之间都必须加空格；
其他：任何运算符左右必须加一个空格(赋值运算符=、逻辑运算符&&、加减乘除符号、三目运行符等)；
缩进采用 4 个空格，禁止使用 tab 字符；
方法体内的执行语句组、变量的定义语句组、不同的业务逻辑之间或者不同的语义之间插入一个空行。相同业务逻辑和语义之间不需要插入空行；
方法与方法之间插入空行。
强烈建议：空行和空格不可或缺，但也不能过多，除缩进以外，其他需要的地方，一行空行或一格空格即可。

文件编码格式规范
没经历过的不知道，经历过的都知道其中的痛~
为了便于协作、后续维护等操作，强烈建议开发者在开发项目之前，先设置编译器的文件编码格式。
编译器 (Eclipse\Android Studio…) 的 text file encoding 设置为 UTF-8，避免采用 GB 相关编码格式(极易造成乱码)，关于设置方法，请自行搜索所用编译器的具体操作。

Log规范
开发时，为了便于调试，经常会打 Log，Android 编程允许直接调用系统的 Log.*(…) 方法来输出 Log，而应用打包后，一般都希望不再输出 Log，虽然可以通过混淆的方式来控制打包后的应用程序是否输出 Log，但是为了更方便的管理 Log，强烈建议摒弃直接调用，转而采用调用经过自行改造的 Log 类，比如自定义 DebugLog 类。Debug 类中，添加一个可以控制是否输出 Log 的变量即可轻松管理 Log 输出与否。如需控制不同等级的 Log 输出情况，也可以添加不同等级的 Log 控制标志。
例：

public final class DebugLog {    private static final String TAG = "DebugLog-";    public static boolean isAllowDebug = true; // Log输出标志    public static void e(String logMsg) {        if (isAllowDebug) {            StackTraceElement caller = getCallerStackTraceElement();            String tag = TAG + generateTag(caller);            Log.e(tag, logMsg);        }    }  public static void e(String tag, String logMsg) {        if (isAllowDebug) {            StackTraceElement caller = getCallerStackTraceElement();            tag = generateTag(caller) + tag;            Log.e(TAG + tag, logMsg);        }    } // 其他等级的log，自行实现，此处省略  /**     * 生成tag(包含调用位置相关信息：类名、方法名、行号)     *     * @param caller     * @return     */    private static String generateTag(StackTraceElement caller) {        String tag = "%s.%s(Line:%d)"; // 占位符        String callerClazzName = caller.getClassName(); // 获取到类名        callerClazzName = callerClazzName.substring(callerClazzName                .lastIndexOf(".") + 1);        tag = String.format(tag, callerClazzName, caller.getMethodName(),                caller.getLineNumber()); // 替换        return tag;    }    private static StackTraceElement getCallerStackTraceElement() {        return Thread.currentThread().getStackTrace()[4];    }}

层次规范
关于层次规范，主要考虑的是逻辑代码的分包、分类、分方法等相关层次，试想，某个包中写了十余个 Activity 类，又写了几个网络请求相关的工具类，以及其他的功能类，其中一个类写了数千行的代码，其中的某个方法写了数百行的代码，这样的代码怎么去阅读？怎么去理解？怎么去修改？
良好的分包、分类、分方法，是产出良好代码的基础。
分包：可以根据功能、属性、模块等来分，比如 Activity 类都放在 com.xx.ui.activity 包中，各工具类都放在 com.xx.util 包中，如果项目的模块区分明显，也可以分包为 com.xxx.model.yyy.activity、com.xxx.model.zzz.activity 等，具体分包，以明确类的归属为准。
分类：每个类仅包含相关的、直接的代码，比如 HomeActivity 中需要展示网络请求得到的数据，如果把网络请求的逻辑、数据格式化的逻辑都写到 HomeActivity 中，则 HomeActivity 类会显得臃肿不堪，逻辑关系难以理解。如果采用合理分类，则 HomeActivity 类中只写入 UI 的相关操作和网络请求的发起，具体的网络请求的处理，则写到具体的网络请求工具类中，类似的，其他功能模块，也都写到对应的类中，这样 HomeActivity 中的代码就会比较简洁，易于理解。
分方法：如果一个方法写了数百行或者一次需要传入过多的参数，则建议把方法拆分开来，形成相关的子方法，这样做的明显好处就是方法简短(代码量、参数数量)、便于理解、易于复用。

此处建议参阅《Effective Java》，此书需要要有空就翻，切记。

大多数程序员都可以写出能运行的代码，但只有少数程序员才能写出其他程序员也能看懂的代码。

欢迎关注我的公众号：Android码农生活