Clean Code代码规范
1、有意义的命名
1.1、名副其实
知道函数发生了什么，传入什么，返回什么
1.2、避免误导
避免留下隐藏代码本意的错误线索
1.3、做有意义的区分
废话是另外一种没有意义的区分
1.4、使用读得出来的名称
读起来像人话
1.5、使用可搜索的名称
2、类名
2.1、类名和对象名应该是名词或者名词短语
如Customer 、WikiPage、 AddressParser,避免使用Manager、 Processor 、Data 、Info 模糊的类名，也不应当是动词。
3、方法名
3.1、应该是动词或者动词短语
3.2、属性访问、修改器和断言
依Javabean标准加get、set和is前缀 如employee.getName(), .setName("mike");,.isPosted()
3.3、重载构造器，使用描述了参数的静态工厂方法。
Complex fulcrumPoint = Complex.FromRealNumber(23.0)好于new的方式，构造器设为private，强制使用（多种）
3.4、别用双关语
避免将统一概念用于不同的目的，统一术语用于不同概念。代码作者尽量写出让别人易于理解的代码，一目尽览，而不必让人殚精竭虑研究。正例：add 、append 、insert。
3.5、使用解决方案领域名称，如设计模式相关命名
3.6、集中精力于把代码写得就像词句篇章（可读性）
4、避免使用编码，避免思维映射
4.1、 java不需要变量类型编码（匈牙利语标记法）
对象是强类型的，编辑环境已经可以解决类型错误
4.2、成员前缀--不必用m_表示成员前缀
应使用某种高亮或者颜色标识出成员的环境
4.3、接口和实现--不建议加接口标示I或者Interface
加实现Imp后缀好于前者，或者也可以不加
4.4、避免思维映射-变量名称明确是王道！
专业程序员善用其能，编写其他人能读懂的代码。
5、函数
5.1、短小 < 15行
函数的第一规则是短小，第二规则是更短小。每个函数都只说一件事，每个函数都一目了然。每个函数都依序把你带到下一个函数。15行？
5.2、代码块和缩进（不超过三层）
if else while语句等，其中的代码块应该只有一行，即函数调用语句，以保持函数短小
函数的缩进级不应该多于三层
5.3、只做一件事
函数应该只做一件事，做好这件事。只做这一件事。判断函数是否不止做了一件事的方法，看是否能再抽出一个函数。函数中如果存在多个区段，表明函数做的事情不止一件。
5.4、每个函数一个抽像层级
每个函数一个抽像层级。确保函数只做一件事，函数中所有的语句都在一个抽象层级上。函数中混杂不同抽象层级，往往让人迷惑，更恶劣的是，就像破损的窗户，一旦细节与基础概念混杂，更多的细节就会在函数中纠结起来
5.5、自顶向下阅读代码：向下规则
让每个函数后面都跟着位于下一抽象层级的函数，在查看函数列表时，就能依抽象层级向下阅读。
5.6、确保每个switch都埋藏在较低的抽象层级，而且永远不重复
5.7、使用描述性的名称
使用描述性的名称：函数越短小，功能越集中，就越便于取个好名字
长而具有描述性的名称，比短而令人费解的名称好。长而具有描述性的名称，要比描述性的长注释好。让函数名称中的多个单词容易阅读，然后使用这些单词给函数取个能说清其功用的名称。别害怕花时间取名字，尝试不同的名称，实测阅读效果。选择描述性的名称能理清你关于模块的设计思路，并帮你改进。追索好名称，往往导致对代码的改善重构。命名方式要保持一致。使用与模块名一脉相承的短语、名词和动词给函数命名。使用类似措辞，依序讲出一个故事。
5.8、函数参数，最好没有，尽量避免三个
足够特殊理由才能用三个以上参数。从测试角度看，参数更叫人为难。
5.9、标识参数 ，这是标识函数不止做一件事情的明确信号，应该拆分。
5.10、二元函数，尽量改写为一元函数
利用一些机制将其转换为一元函数。（多个参数封装成临时类，不是一个好的解决方式）
5.11、函数和参数应当形成一种非常良好的动/、名词对形式
如assertEqual 改成assertExpectedEqualsActual（expected，actual）大大减轻记忆参数顺序的负担。
5.12避免使用输出参数
如果函数必须要修改某种状态，就修改所属对象的状态。
5.13、分隔指令与询问
函数要么做什么事 要么回答什么事，但二者不可得兼。
函数应该修改某对象的状态，或是返回该对象的有关信息。两样都干常会导致混乱。
5.14、使用异常替代返回错误码。
从指令式函数返回错误码轻微违反了指令与询问分隔的规则。鼓励了在if语句判断中把指令当做表达式使用。另一方面，如果使用异常替代返回错误码，错误处理代码就能从主路径径代码中分离出来，得到简化。
5.15、抽离Try/Catch代码块。
Try/Catch代码丑陋不堪。他们搞乱了代码结构，把错误处理与正常流程混为一谈。把try和catch代码块的主体部分抽离出来，另外形成函数。
函数应该只做一件事。错误处理就是一件事。因此，处理错误的函数不应该做其他的事，如果关键字try在某个函数中存在，它就应该是这个函数的第一个单词，而且在catch/fianlly代码块后面也不应该有其他内容。
5.16、别重复自己
重复可能是软件中一切邪恶的根源。许多原则与实践规则都是为控制与消除重复而创建。如面向对象将代码集中到积累，避免冗余。
5.17、如何写出好的函数
写代码和写别的东西很像，在写论文或者文章时，你先想什么就写什么，然后再打磨它。初稿也许粗陋无序，你就斟酌推敲，直至达到你心目中的样子。
我写函数时，一开始都冗长而复杂。有太多缩进和嵌套循环。有过长的参数列表。名称时随意取的，也会有重复的代码。不过我会配上一套单元测试，覆盖每行丑陋的代码。 然后我打磨这些代码，分解函数、修改名称、消除重复。我缩短和重新安置方法。有时我还拆散类。同时保持测试通过。
最后，遵循本章列出的规则，我组装好这些函数。我并不从一开始就按照规则写函数。我想没人做得到。
5.17、小结
每个系统都是使用某种领域特定语言搭建，而这种语言是程序员设计来描述那个系统的。
函数是语言的动词（描述具体做了什么事），类是名词。这并非是退回到那种认为需求文档中的名词和动词就是系统中类和函数的最初设想的可怕的旧观念。其实，这是个历史悠久的真理。编程艺术是是且一直是一门语言设计的艺术。大师级程序员把系统当做故事来讲，而不是当做程序来写。他们试用选定编程语言提供的工具构建一种更为丰富且更具表达力的语言，用来讲那个故事。那种领域特定语言的一个部分，就是描述在系统中发生的各种行为的函数层级。在一种狡猾的递归操作中，这些行为适用他们定义的与领域紧密相关的语言讲述自己那个小故事。
本章所讲述的是有关编写良好函数的机制。如果你遵循这些规则，函数就会短小，有个好名字而且被很好低归置。不过永远别忘记，真正的目标在于讲述系统的故事，而你编写的函数必须干净利落地拼装到一起，形成一种精确而清晰的语言，帮助你讲故事。
6、代码布局
6.1、垂直原则
6.1.1 归组
如果代码属于以下情形，代码应归于一组，组之间用空行分隔
1.实现同一功能的
2.执行同类任务的（错误处理等）
3.属性相同的（变量类型等）
4.有相互调用关系的
6.1.2 单个文件垂直大小不超过500行（<5%）
6.2、水平原则：
6.2.1、单行代码中，要准确的使用空格，
1.赋值操作符周围加空格
2.参数间逗号后加空格
3.优先级低的运算符与前后项加空格
4.优先级高的运算符与前后项不加空格
5.函数名和参数之间不加空格6.2.2、代码块中，遇到新的继承结构要缩进
6.2.3、单行代码水平宽度不超过80字符
7、 注释
7.1、写注释前，先仔细考虑是否可以优化代码的描述方式
7.2、 注释和代码是应是同步的
7.3、 注释是意义明确的，不需要自解释
7.4、注释只说明代码为什么这样写，而非怎样写
7.5、警告、版权协议、公共API是必需写的注释
http://210.21.236.159/cleanCo...