Java代码规范

目录

 

意义

目的

方法

属性 (property)

常量 (const)

字段和变量

注释原则

---

意义

   编码规范对于程序员而言尤为重要，做好代码规范，我们将获益良多：

1. 一个软件的生命周期中，80%的花费在于维护，代码规范降低了金钱成本和时间成本；
2. 几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护，代码规范减少了工作交接过程中的交流成本。

3.  规范可以改善软件的可读性，可以让程序员尽快而彻底地理解新的设计和代码，节约了时间，提高了工作效率。

4.  良好的编码规范可以有效避免一些低级错误，赢得同事的夸奖和上司的认可。

 

目的

  1．统一规范，方便阅读、维护，提高代码质量

  2. 统一格式，使代码度量更加精确，为公司软件过程体系优化打好基础，为后续交接工作提供依据。

 

方法

1. 增加/插入的方法用add作为前缀；

正例：add*/addGrade()

1. 删除的方法用delete作为前缀；

正例：delete*/deleteGrade()

1. 更改/更新的方法用update作为前缀；

正例：update*/updateGrade()

1. 查询/获取单个对象的方法用find作为前缀；

正例：find*/findGrade()

1. 查询/获取多个对象的方法用query作为前缀；

正例：query*/queryStudentList()

在具体任务开发中，如果有特定的命名约定，则在相应的软件开发计划中予以明确定义及上报质量管理部审计组。

 

属性 (property)

1. 以名词或形容词命名。
2. 使用 Pascal 大小写。
3. 禁止缩写。
4. javabean属性命名尽量使用常规的驼峰式命名规则
5. 属性名第一个单词尽量避免使用一个字母：如eBook， eMail。
6. boolean属性名避免使用 "is" 开头的名称，因为javabean规范的boolean取值操作是isXXX
7. 在类属性的名称中包含类名是多余的，如 Book.BookTitle。而是应该使用 Book.Title。

 

常量 (const)

1. 禁止缩写。
2. 采用完整的英文大写单词，在词与词之间用下划线连接，如：DEFAULT_VALUE。
3. 命名尽量简短，不要超过16个字符
4. 同一组的常量可以用常量类封装在一起，便于引用和维护
5. 代码中用到常量的，用静态常量表示，

正例：

Private final static String SUCCESS=”success”;

Private final static String ERROR = “error”;

调用：类名.SUCCESS 

 

字段和变量

1. private、protected 使用 Camel 大小写。
2. 禁止使用public。
3. 字段命名规范：驼峰命名 比如：studentName,studentId
4. 对于主键字段， id命名:如：studentId，需要加上与实体类相关的名称。
5. 对于时间类型的字段，采用dateTime,  格式：YYYY-MM-dd HH:mm:ss
6. 布尔变量名应该包含 Is，这意味着 Yes/No 或 True/False 值，如 fileIsFound。
7. DataSet类型的变量以ds开头，DataTable类型的变量以table开头
8. 在变量名中使用互补对，如 min/max、begin/end 和 open/close。
9. 即使对于可能仅出现在几个代码行中的生存期很短的变量，仍然使用有意义的名称。仅对于短循环索引使用单字母变量名，如 i 或 j。
10. 对不易清楚识别出该变量类型的变量应使用类型缩写作其前缀，如字符串使用strXXX,boolean使用isXXX，hasXXX等等。
11. 命名尽量简短，不要超过16个字符

注释原则

1. 一般情况下，源程序的有效注释量必须在30%以上。

1. 避免使用装饰性内容，保持注释的简洁。
2. 注释信息不仅要包括代码的功能，还应给出原因，不要为注释而注释。
3. 除变量定义等较短语句的注释可用行尾注释外，其他注释当避免使用行尾注释。
4. 注释类型：javadoc注释，失效代码注释(eclipse下ctrl+shift+/),代码细节注释 //。
5. 对类、方法、变量等的注释需要符合JavaDoc规范，对每个类、方法都应详细说明其功能、条件、参数等，并使用良好的HTML标记
6. 格式化注释，以使生成的JavaDoc易阅读和理解。
7. 如果注释太复杂说明程序需要修改调整，使设计更加合理。
8. getter、setter方法不用注释
9. 注释不能嵌套
10. 生成开发文档的需要用中文编写
11. 如果需要注释的内容太多，需附加文档进行说明， 注释时加上"参见《****》"
12. 距离较远的}必须注释
13. 复杂的分支流程必须注释
14. 代码质量不高但能正常运行，或者还没有实现的代码用//TODO:声明

1. 存在错误隐患的代码用//FIXME:声明