Java编码风格
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
每个软件开发人员必须一致遵守编码规范。
目录
1. 总则 .................................................................................................................................................. 1 2. 格式约定 ........................................................................................................................................... 3 3. 命名约定 ......................................................................................................................................... 11
u 简单性：构造简单Hale Waihona Puke Baidu类和方法。确定你需要做多少才能满足用户的需求。 u 清晰性：确保每一个类、接口、方法、变量和对象具有明确的用途；说明哪里、何时、何种原因
和如何使用它们。 u 完整性：提供任何合理用户期望获取和使用的最低限度的程序功能。编写完整的说明文档，记录
所有的特征和功能。 u 一致性：相似的实体在外观和行为上应该一致，反之亦然。尽可能建立并遵守标准。 u 健壮性：为错误和异常做法预测，并将解决方法写入文档。不要隐藏错误也不要等着用户自己去
★ 坚持最少惊讶的原则（2）
最少惊讶原则的意思是：避免做一些让用户感到惊讶的事。这就意味者，软件展现的交互和行为方式 必须是可预示的并且一致的。否则，文档必须对所有的非常规用法或行为明确的指示出来，并给出正当理 由。
将用户在使用软件中遇到意外情况的可能性降到最低，必须在 java 软件的设计、实现和文档编写中遵 循以下几点：
1. 总则
对于职业的 Java 开发人员，写出运行良好的软件是至关重要的，但是同时他还应该考虑其他问题。所 有优秀的软件都运行良好。但是卓越的软件有自己的编码风格，它是可预测的、健壮的、可维护的、可支 持的并且可扩展的。
★ 保持原有风格（1）
当修改原有软件时，修改后的代码应该保持原有代码的风格。不要试图在修改时引入一种新的编码风 格，也不要试图为了迎合新的编码风格而重写原有软件。因为在同一份代码中使用不同的编码风格，使得 代码难以阅读和理解。在重写代码时，简单的修改编码风格，会导致代价惨重的缺陷，而本来这些是可以 避免的。
3.1. 包命名................................................................................................................................... 12 3.2. 类型命名................................................................................................................................ 13 3.3. 接口命名................................................................................................................................ 15 3.4. 方法命名................................................................................................................................ 15 3.5. 变量命名................................................................................................................................ 17 3.6. 成员变量................................................................................................................................ 19 3.7. 参数命名................................................................................................................................ 19 3.8. 常量命名................................................................................................................................ 20 4. 文档约定 ......................................................................................................................................... 21 4.1. 注释类型................................................................................................................................ 21 4.2. 文档注释................................................................................................................................ 23 4.3. 注释风格................................................................................................................................ 24 4.4. 注释内容................................................................................................................................ 31 4.5. 内部注释................................................................................................................................ 33 5. 编程约定 ......................................................................................................................................... 37 5.1. 类型安全................................................................................................................................ 41 5.2. 语句与表达式......................................................................................................................... 43 5.3. 构造....................................................................................................................................... 45 5.4. 异常处理................................................................................................................................ 46 5.5. 断言....................................................................................................................................... 48 5.6. 并发....................................................................................................................................... 50 5.7. 同步....................................................................................................................................... 51 5.8. 效率....................................................................................................................................... 54 6. 包约定............................................................................................................................................. 57 7. 总结 ................................................................................................................................................ 59
Ｊａｖａ
编 程 风 格
对于任何工程项目来说，统一的施工标准都是保证工程质量的重要因素。编码规范对于程序员而言尤
为重要，有以下几个原因：
u 在软件的生命周期中，维护时间花费了大概 80%； u 在整个生命周期中，几乎没有软件均由最初的开发人员来维护； u 编码规范可以改善软件的可读性，可以让程序员尽快而彻底地理解新的代码；
发现错误。
★ 第一次就把事情作对（3）
好的开始是成功的一半。 将项目规定的编码规则应用到所有你写的代码中，而不仅仅在产品本身的代码上。通常，许多段原型 代码或者试验代码会被写入到最终产品中，所以你应该预见这种可能性。即使这些不会成为产品代码的一 部分，你的代码总还是会被其他人读到。任何阅读你代码的人，都因你从在一开始就一贯应用这些规则而 赞美你的职业作风和先见之明。
目录
1. 总则 .................................................................................................................................................. 1 2. 格式约定 ........................................................................................................................................... 3 3. 命名约定 ......................................................................................................................................... 11
u 简单性：构造简单Hale Waihona Puke Baidu类和方法。确定你需要做多少才能满足用户的需求。 u 清晰性：确保每一个类、接口、方法、变量和对象具有明确的用途；说明哪里、何时、何种原因
和如何使用它们。 u 完整性：提供任何合理用户期望获取和使用的最低限度的程序功能。编写完整的说明文档，记录
所有的特征和功能。 u 一致性：相似的实体在外观和行为上应该一致，反之亦然。尽可能建立并遵守标准。 u 健壮性：为错误和异常做法预测，并将解决方法写入文档。不要隐藏错误也不要等着用户自己去
★ 坚持最少惊讶的原则（2）
最少惊讶原则的意思是：避免做一些让用户感到惊讶的事。这就意味者，软件展现的交互和行为方式 必须是可预示的并且一致的。否则，文档必须对所有的非常规用法或行为明确的指示出来，并给出正当理 由。
将用户在使用软件中遇到意外情况的可能性降到最低，必须在 java 软件的设计、实现和文档编写中遵 循以下几点：
1. 总则
对于职业的 Java 开发人员，写出运行良好的软件是至关重要的，但是同时他还应该考虑其他问题。所 有优秀的软件都运行良好。但是卓越的软件有自己的编码风格，它是可预测的、健壮的、可维护的、可支 持的并且可扩展的。
★ 保持原有风格（1）
当修改原有软件时，修改后的代码应该保持原有代码的风格。不要试图在修改时引入一种新的编码风 格，也不要试图为了迎合新的编码风格而重写原有软件。因为在同一份代码中使用不同的编码风格，使得 代码难以阅读和理解。在重写代码时，简单的修改编码风格，会导致代价惨重的缺陷，而本来这些是可以 避免的。
3.1. 包命名................................................................................................................................... 12 3.2. 类型命名................................................................................................................................ 13 3.3. 接口命名................................................................................................................................ 15 3.4. 方法命名................................................................................................................................ 15 3.5. 变量命名................................................................................................................................ 17 3.6. 成员变量................................................................................................................................ 19 3.7. 参数命名................................................................................................................................ 19 3.8. 常量命名................................................................................................................................ 20 4. 文档约定 ......................................................................................................................................... 21 4.1. 注释类型................................................................................................................................ 21 4.2. 文档注释................................................................................................................................ 23 4.3. 注释风格................................................................................................................................ 24 4.4. 注释内容................................................................................................................................ 31 4.5. 内部注释................................................................................................................................ 33 5. 编程约定 ......................................................................................................................................... 37 5.1. 类型安全................................................................................................................................ 41 5.2. 语句与表达式......................................................................................................................... 43 5.3. 构造....................................................................................................................................... 45 5.4. 异常处理................................................................................................................................ 46 5.5. 断言....................................................................................................................................... 48 5.6. 并发....................................................................................................................................... 50 5.7. 同步....................................................................................................................................... 51 5.8. 效率....................................................................................................................................... 54 6. 包约定............................................................................................................................................. 57 7. 总结 ................................................................................................................................................ 59
Ｊａｖａ
编 程 风 格
对于任何工程项目来说，统一的施工标准都是保证工程质量的重要因素。编码规范对于程序员而言尤
为重要，有以下几个原因：
u 在软件的生命周期中，维护时间花费了大概 80%； u 在整个生命周期中，几乎没有软件均由最初的开发人员来维护； u 编码规范可以改善软件的可读性，可以让程序员尽快而彻底地理解新的代码；
发现错误。
★ 第一次就把事情作对（3）
好的开始是成功的一半。 将项目规定的编码规则应用到所有你写的代码中，而不仅仅在产品本身的代码上。通常，许多段原型 代码或者试验代码会被写入到最终产品中，所以你应该预见这种可能性。即使这些不会成为产品代码的一 部分，你的代码总还是会被其他人读到。任何阅读你代码的人，都因你从在一开始就一贯应用这些规则而 赞美你的职业作风和先见之明。