算法第一章作业：编码规范与《数学之美》读后感

编码规范：Java编码规范

命名

【规范】类名使用UpperCamelCase 风格，必须遵从驼峰形式，但以下情形例外： （ 领域模型的相关命名 ）DO / BO / DTO / VO 等。

正例： MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion

反例： macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion

 

【规范】方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase 风格，必须遵从驼峰形式。

正例： localValue / getHttpMessage() / inputUserId

 

【规范】常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。

 

【规范】抽象类命名使用 Abstract 或 Base 开头 ； 异常类命名使用 Exception 结尾 ； 测试类命名以它要测试的类的名称开始，以 Test 结尾。枚举类名建议带上 Enum 后缀，枚举成员名称需要全大写，单词间用下划线隔开。

 

【规范】POJO 类中布尔类型的变量，都不要加 is ，否则部分框架解析会引起序列化错误。

 

【规范】各层命名规约：

A) Service / DAO 层方法命名规约

1 ） 获取单个对象的方法用 get 做前缀。

2 ） 获取多个对象的方法用 list 做前缀（习惯：getXXXList）。

3 ） 获取统计值的方法用 count 做前缀。

4 ） 插入的方法用 save（ 推荐 ） 或 insert 做前缀。

5 ） 删除的方法用 remove（ 推荐 ） 或 delete 做前缀。

6 ） 修改的方法用 update 做前缀(或modify)。

B) 领域模型命名规约

1 ） 数据对象： xxxDO ， xxx 即为数据表名。

2 ） 数据传输对象： xxxDTO ， xxx 为业务领域相关的名称。

3 ） 展示对象： xxxVO ， xxx 一般为网页名称。

4 ） POJO 是 DO / DTO / BO / VO 的统称，禁止命名成 xxxPOJO 。

 

常量

【规范】不允许任何未经定义的常量直接出现在代码中。

 

格式规约

【风格】单行太长需换行

 

【风格】方法体内的执行语句组、变量的定义语句组、不同的业务逻辑之间或者不同的语义之间插入一个空行。相同业务逻辑和语义之间不需要插入空行。

 

集合处理

【强制】关于 hashCode 和 equals 的处理，遵循如下规则：

1） 只要重写 equals ，就必须重写 hashCode 。

2） 因为 Set 存储的是不重复的对象，依据 hashCode 和 equals 进行判断，所以 Set 存储的对象必须重写这两个方法。

3） 如果自定义对象做为 Map 的键，那么必须重写 hashCode 和 equals 。

 

【规范】集合初始化时，尽量指定集合初始值大小。

说明： ArrayList 尽量使用 ArrayList(int initialCapacity) 初始化。

 

【规范】使用 entrySet 遍历 Map 类集合 KV，而不是 keySet 方式进行遍历。

说明:keySet 其实是遍历了 2 次，一次是转为 Iterator 对象，另一次是从 hashMap 中取出 key 所对应的 value。而 entrySet 只是遍历了一次就把 key 和 value 都放到了 entry 中，效 率更高。如果是 JDK8，使用 Map.foreach 方法。

 

控制语句

【规范】在一个 switch 块内，每个 case 要么通过 break/return 等来终止，要么注释说明程 序将继续执行到哪一个 case 为止;在一个 switch 块内，都必须包含一个 default 语句并且 放在最后，即使它什么代码也没有。

 

【规范】在 if/else/for/while/do 语句中必须使用大括号，即使只有一行代码，避免使用 下面的形式:if (condition) statements;

 

【规范】推荐尽量少用 else， if-else 的方式可以改写成:

if(condition){

...

return obj; }

// 接着写 else 的业务逻辑代码;

说明:如果非得使用if()...else if()...else...方式表达逻辑，【强制】请勿超过3层。

 

注释规约

【规范】类、类属性、类方法的注释必须使用 Javadoc 规范，使用/**内容*/格式，不得使用 //xxx 方式。

 

【规范】所有的抽象方法(包括接口中的方法)必须要用 Javadoc 注释、除了返回值、参数、 异常说明外，还必须指出该方法做什么事情，实现什么功能。

说明:对子类的实现要求，或者调用注意事项，请一并说明。

 

【风格】方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释使用/* */注释，注意与代码对齐。

 

【规范】所有的枚举类型字段必须要有注释，说明每个数据项的用途。

 

【规范】代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑 等的修改。

 

【规范】注释掉的代码尽量要配合说明，而不是简单的注释掉。

说明:代码被注释掉有两种可能性:

1)后续会恢复此段代码逻辑。

2)永久不用。前者如果没 有备注信息，难以知晓注释动机。

后者建议直接删掉(代码仓库保存了历史代码)。

 

【风格】特殊注释标记，请注明标记人与标记时间。注意及时处理这些标记，通过标记扫描， 经常清理此类标记。线上故障有时候就是来源于这些标记处的代码。

1) 待办事宜(TODO):( 标记人，标记时间，[预计处理时间]) 表示需要实现，但目前还未实现的功能。这实际上是一个 Javadoc 的标签，目前的 Javadoc

还没有实现，但已经被广泛使用。只能应用于类，接口和方法(因为它是一个 Javadoc 标签)。

2) 错误，不能工作(FIXME):(标记人，标记时间，[预计处理时间])

在注释中用 FIXME 标记某代码是错误的，而且不能工作，需要及时纠正的情况。

 

阅读

《数学之美》第八章“简单之美”的读后感

　　本章可以引用牛顿曾说的一句话：“发觉真理在形式上从来是最简单的，而不是复杂和含混的”

　　技术分为两种：术和道，术是做事的基本方法，道是原理和原则，追求术的人一辈子都很辛苦，而追求道的人才能游刃有余；因此，Google搜索质量的第一负责人每天都会分析那些不好的搜索结果，但是有非常多的搜索工程师就做不到这一点，他们总想着用一个算法就搞定，毕其功于一役；

　　举个例子：搜索引擎。我们平常所用的百度，Google的浏览器搜索所需要的资料，在仅仅零点几秒内，便可以得到成千上百的搜索结果。根据书本所述，这些浏览器公司都有一套自己的算法，根据访问频率、信息质量......等信息，建立不同级别的索引，无论从表面上看搜索引擎有多复杂，原理上依旧简单--布尔代数。

　　想起我算法老师的一句话：最厉害、高效的算法==最简洁、易懂的代码！