首先分享一句我比较喜欢的话 “任何一个傻瓜都能写出计算机可以理解的代码，唯有写出人类容易理解的代码才是优秀的程序员”。所以今天和大家分享一下入门级的编码规范，可能更适合在校生纠正自己的编码习惯，在初入职场时可以更快的融入团队。
1. 命名规范
这里总结的其实还是比较模糊的，我也看过一些网上的文章，个人感觉太长又比较枯燥，不太愿意读下去，所以这里基本是提纲式的总结，给大家提供需要注意哪些点的认知，一些具体细微的命名规范需要大家自己在使用中去探索，这样也才能更好的消化。
首先了解下 Java 编程比较常见的三种命名方式：
驼峰（Camel）命名法：又称小驼峰命名法，除首单词外，其余所有单词的第一个字母大写。
帕斯卡（pascal）命名法：又称大驼峰命名法，所有单词的第一个字母大写。
下划线命名法：单词与单词间用下划线做间隔 。
1.1. 包命名
采用反域名命名规则，全部使用小写字母。建议采用如下规则：[com].[公司名/组织名].[项目名称].[模块名]
例如： com.liuwan1992.testproject.presenter
这里值得思考一下的是模块名的划分，我目前习惯用 MVP 模式组织工程架构，感兴趣的可以了解下。
1.2. 类命名
名词，采用大驼峰命名法，尽量避免缩写，除非该缩写是众所周知的，如 URL，JSON 等。
这里举个例子，比如 Activity，命名格式应该是 XxxxActivity（Xxxx 表示该 Activity 的功能），例如开屏界面可以命名为 SplashActivity。
1.3. 接口命名
我个人比较喜欢的是以接口功能命名，并在接口名前加一个大写的 I，表明这是一个 Interface。例如一个用于刷新界面的接口，可以命名为 IRefreshView。
1.4. 方法命名
动词或动名词，采用小驼峰命名法。
比如初始化控件的方法可以命名为 initView()，用于判断日期格式合法性的方法命名为 isDateFormatValidity()。
1.5. 变量命名
采用小驼峰命名法，需要对不同作用域的变量进行区分：
成员变量命名前面加 m，如
mWidth静态类变量前面加 s，如
sSingleInstance
1.6. 常量命名
全部大写，采用下划线命名法，如 MAX_WIDTH。
1.7. 布局资源文件命名
全部小写，采用下划线命名法。
比如 Activity 的布局文件，命名格式应该是 activity_xxxx（xxxx 表示该 Activity 的功能），例如开屏界面的布局文件可以命名为 activity_splash。
1.8. 控件 id 命名
全部小写，采用下划线命名法。
个人习惯以控件缩写作为前缀，例如登录按钮（Button）的 id 可以命名为 btn_login。更多控件的常用缩写方式多看些代码就可以了解了。
2. 编码风格
2.1. 如何起名字
命名规范就是类似手册一样的工具书，很基础，不需要过多思考。但是一个好的命名还需要能把信息装到名字里，让别人通过名字就能获得很多信息。
这里说个我遇到的事，毕业时帮同学调试代码，他给我看整个工程的时候，里面所有类的名字都是 A1、A2….A21 这样子，简直是手动混淆，我震惊之余也挺佩服他还能分得清这些是干嘛的。
当然，这种方式是不可取的，下面说几点关于命名的思路：
使用专业的单词：例如，不用 Get，而用 Fetch 或者 Download 可能会更好，这由上下文决定。
避免空泛的名字：像 tmp 和 retval，除非使用它们有特殊的理由。
使用具体的名字来更细致地描述事物：ServerCanStart() 这个名字就比 CanListenOnPort 更不清楚。
给变量名带上重要的细节：例如，在值为毫秒的变量后面加上
_ms，或者在还需要转义的，未处理的变量前面加上raw_。为作用域大的名字采用更长的名字：不要用让人费解的一个或两个字母的名字来命名在几屏之间都可见的变量。对于只存在于几行之间的变量用短一点的名字更好。
有目的地使用大小写、下划线等：例如，你可以在类成员和局部变量后面加上“_”来区分它们。
2.2. 提升代码美感
通过把代码用一致的、有意义的方式“格式化”，可以把代码变得更容易读，并且可以读得更快。这里提一下 Android Studio 格式化的快捷键是 Ctrl + Alt + l。
下面说一些具体技巧：
如果多个代码块做相似的事情，尝试提取为一个公共方法。
如果在一段代码中提到 A、B 和 C，那么不要在另一段中说 B、C 和 A。选择一个有意义的顺序，并始终用这样的顺序。
用空行来把大块代码分成逻辑上的“段落”。
2.3. 必要的使用注释
注释的目的不仅可以帮助别人快速理解你的代码，也可以帮助自己在以后回头修改功能时更快的定位。
一些简单注释的技巧：
这个类、方法或代码块的功能是什么。
代码中的缺陷，使用像
TODO:这样的标记。常量的具体含义。
值得一提的是，注释不该被用来粉饰烂代码，注释只是用来更好地帮助理解，烂代码需要从根本上去优化。
2.4. 简化代码逻辑
对于嵌套很深的代码可以提早返回减少嵌套并让代码整洁，比如：
if(a = 1) { if(b = 1) { ...... } }可以改成：
if(a != 1) return; if(b != 1) return; ......这里只是一个简单的思路，具体使用还需要结合实际讨论。
用德摩根定理来操作逻辑表达式，例如
if(!(a && b))变成if(!a || !b)。
2.5. 重视代码警告
在编码过程中会有遇到一些代码检查的警告，大多数的警告还是比较有用的，不少人认为警告并不影响运行不用理会，但警告确实说明了代码里面可能潜在的风险，所以对于警告还是应该视合理性去解决掉。
2.6. 其它
还有很多值得探讨的良好编码风格，比如避免使用魔法值，代码的缩进、换行等等，平时在阅读别人写的比较“美”代码时需要注意学习其中的思想。
3. 重新组织代码
3.1. 抽取不相关的子问题
把一般代码和项目专有的代码分开，通过建立一大组库和辅助函数来解决一般问题，剩下的只是让你的程序与众不同的核心部分。它使你只需关注小而定义良好的问题，这些问题已经同项目的其他部分脱离。其结果是，对于这些子问题的解决方案倾向于更加完整和正确，你也可以在以后重用这些库和辅助函数。
3.2. 一次只做一件事
如果你有很难读的代码，尝试把它所做的所有任务列出来。其中一些任务可以很容易地变成单独的函数（或类）。其他的可以简单地成为一个函数中的逻辑“段落”。具体如何拆分这些任务没有它们已经分开这个事实那样重用。难的是要准确地描述你的程序所做的所有这些小事情。
3.3. 少写无用代码
写越少代码越好。每行新的代码都需要测试和维护。另外，代码库中的代码越多，它就越“重”，而且在其上开发就越难。可以通过以下方法避免编写新代码：
从项目中消除不必要的功能，不要过度设计。
习惯性的构建和使用工具类或辅助函数。
经常性地通读标准库的整个 API，保持对它们的熟悉程度，例如字符串判空可以使用
!TextUtils.isEmpty(str)，而不是str != null && !"".equals(str)。
关于代码可读和重构的知识太多了，这里没有深入地进行探讨，只是以我的亲身经历简单地提了一些对于入门级需要重视的点，希望可以帮助刚开始编程或有需要的人构建一个基本认知，并在此基础上不断深入研究。