一、在程序的版式上
1、程序块要采用缩进风格编写 ，缩进的空格数为 4 个。 原因说明： 由开发工具自动生成的代码可能不一致，但如果开发工具可以配置，则应该统一配 置缩进为 4 个空格。
2、缩进或者对齐只能使用空格键 ，不可使用 TAB 键。说明 ： 使用 TAB 键需要设置 TAB 键的空格数目是 4 格。
3、相对独立的程序块之间，变量说明之后必须加空行。 说明 ： 以下情况应该是用空行分开：
1）函数之间应该用空行分开；
2）变量声明应尽可能靠近第一次使用处，避免一次性声明一组没有马上使用的变量；
3）用空行将代码按照逻辑片断划分；
4）每个类声明之后应该加入空格同其他代码分开。
4、 较长的语句（>80 字符）要分成多行书写。
1）长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行 要进行适当的缩进，使排版整齐，语句可读。
2）若函数或过程中的参数较长，则要进行适当的划分。
3）循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分，长表达式 要在低优先级操作符处划分新行，操作符放在新行之首。
5、不允许把多个短语句写在一行中，即一行只写一条语句。 说明： 一行代码只做一件事情，如只定义一个变量，或只写一条语句。这样的代码容易阅 读，并且方便于写注释。
6、if、for、do、while、case、switch、default default default 等语句自占一行 等语句自占一行，且 if、for、 do、while 等语句的执行语句部分无论多少都要加括号，等语句的执行语句部分无论多少都要加括号{}。
7、代码行之内应该留有适当的空格。说明：采用这种松散方式编写代码的目的是使代码更加清晰。
1）关键字之后要留空格。象 const、virtual、inline、case 等关键字之后至少要留一 个空格， 否则无法辨析关键字。象 if、for、while 等关键字之后应留一个空格再跟左 括号‘（ ’， 以突出关键字。
2）函数名之后不要留空格， 紧跟左括号’(’ ， 以与关键字区别。
3）‘( ’ 向后紧跟，‘ )’、‘ ，’、‘ ;’ 向前紧跟， 紧跟处不留空格。
4）值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符，如“ =”、“ +=” “ >=”、“ <=”、“ +”、“ *”、“ %”、“ &&”、“ ||”、“ <<” 、“ ^” 等二元操作符 的前后应当加空格。
5）一元操作符如“ !”、“ ~”、“ ++”、“ –”、“ &”（ 地址运算符） 等前后不加 空格。 7）象“［ ］”、“ .”、“ ->” 这类操作符前后不加空格。
8、 程序块的分界符（如 C/C++语言的大括号‘{’和‘}’）应各独占一行并且 应各独占一行并且 位于同一列，同时与引用它们的语句左对齐 ，同时与引用它们的语句左对齐。在函数体的开始 。在函数体的开始、类的定义、结构的定义、 枚举的定义以及 if、for、do、while、switch、case 语句中的程序都要采用如上的缩 语句中的程序都要采用如上的缩 进方式。
二、在注释上
1、源文件头部应进行注释，列出：生成日期、作者、模块目的/功能等。
2、函数头部应进行注释，列出：函数的目的/功能、输入参数、输出参数、返回 值等。
3、注释应该和代码同时更新 ，不再有用的注释要删除。
4、注释的内容要清楚，不能有二义性。 说明： 错误的注释不但无益反而有害。
5、避免在注释中使用非常 ：避免在注释中使用非常用的缩写或者术语。
6、注释的主要目的应该是解释为什么这么做，而不是正在做什么。如果从上下 文不容易看出作者的目的，说明程序的可读性本身存在比较大的问题 ，应考虑对其重构。
7、避免非必要的注释
8、注释的版式 说明：注释也需要与代码一样整齐排版 。
1）注释应与其描述的代码相近，对代码的注释应放在其上方或右方（对单条语句的注释）相邻位置，不可放在下面，如放于上方则需与其上面的代码用空行隔开。
2）注释与所描述内容进行同样的缩排。
3）将注释与其上面的代码用空行隔开。
4）变量、常量、宏的注释应放在其上方相邻位置或右方。
9、对于所有有物理含义的变量，如果其命名不是充分自注释的，在声明 时都必须加以注释，说明其物理含义。
10、数据结构声明(包括数组、结构、类、枚举等)，如果其命名不是充分自注释，必须加以注释。对数据结构的注释应放在其上方相邻位置 ，不可放在下面；对结构中的每个域的注释可放在此域的右方。
11、对重要变量的定义需编写注释 ，特别是全局变量，更应有较详细的注释，包 括对其功能、取值范围、以及存取时注意事项等的说明 、以及存取时注意事项等的说明。
12、分支语句（条件分支、循环语句等）需编写注释。 说明： 这些语句往往是程序实现某一特定功能的关键，对于维护人员来说，良好的注释帮助更好的理解程序，有时甚至优于看设计文档。
13、 注释不宜过多 也不能太少，源程序中有效注释量控制在 20％~30%之间。 说明： 注释是对代码的“提示”，而不是文档，不可喧宾夺主，注释太多会让人眼花缭乱。
三、在标识符命名上
1、命名尽量使用英文单词 ：力求简单清楚 ，避免使用引起误解的词汇和模糊的 ，使人产生误解。 说明： 较短的单词可通过去掉“元音”形成缩写；较长的单词可取单词的头几个字母形成缩写；一些单词有大家公认的缩写。
2、命名规范必须与所使用的系统风格保持一致，并在同一项目中统一 ，并在同一项目中统一。 说明
1）如在 UNIX 系统，可采用全小写加下划线的风格或大小写混排的方式，但不能使 用大小写与下划线混排的方式。
2）用作特殊标识如标识成员变量或全局变量的 m_和 g_，其后加上大小写混排的方 式是允许的。
3、常量、宏和模板名采用全大写的方式 、宏和模板名采用全大写的方式，每个单词间用下划线分隔。
4、枚举类型 enum 常量应以大写字母开头或全部大写 enum 常量应以大写字母开头或全部大写。
5、命名中若使用了特殊约定或缩写，则要有注释说明。 说明： 应该在源文件的开始之处，对文件中所使用的缩写或约定，特别是特殊的缩写，进 行必要的注释说明。
6、自己特有的命名风格，要自始至终保持一致，不可来回变化。
8、函数名以大写字母开头，采用谓-宾结构（动-名），且应反映函数执行什么 操作以及返回什么内容。
四、在程序的可读性上
1、用括号明确表达式的操作顺序 ，避免使用默认优先级。
2、不要编写太复杂、多用途的复合表达式。
3、涉及物理状态或者含有物理意义的常量 ，避免直接使用数字，必须用有意义的枚举或常量来代替。
4、禁止使用难以理解，容易产生歧义的语句。
五、在变量、结构上
1、尽量少使用全局变量，尽量去掉没必要的公共变量。 说明： 公共变量是增大模块间耦合的原因之一，故应减少没必要的公共变量以降低模块间 的耦合度。
2、变量被创建之后应当及时把它们初始化，以防止把未被初始化的变量当成右值使用。说明：在 C/C++中引用未经赋值的指针，经常会引起系统崩溃。
3、留心具体语言及编译器处理不同数据类型的原则及有关细节。
4、尽量减少没有必要的数据类型默认转换与强制转换。 说明： 当进行数据类型强制转换时，其数据的意义、转换后的取值等都有可能发生变化。
5、当声明用于分布式环境或不同 CPU 间通信环境的数据结构时 CPU 间通信环境的数据结构时，必须考虑机器 的字节顺序、使用的位域及字节对齐等问题 、使用的位域及字节对齐等问题。 说明：
1）在 Intel CPU 与 SPARC CPU，在处理位域及整数时，其在内存存放的“顺序”正 好相反。
2）在对齐方式下，CPU 的运行效率要快一些。
六、C++专用规范
1、在高警告级别下干净地编译。 使用编译器的最高警告级别。要求干净的（没有警告的）构建（build）并理解所有 的警告。通过修改代码来消除警告，而不是通过降低警告级别来消除。对于明确理解其 含义，确信不会造成任何问题的警告，则可以局部关闭。
2、确保资源为对象所占有，使用显式的 RAII 和智能指针 RAII 和智能指针。
3、主动使用 const，避免使用宏。 应该尽可能的使用常量而不用变量，另外在定义数值的时候，应该把 const 做为默 认的选项。
4、合理使用组合(composition)和继承 (composition)。 继承是 C++中耦合度最强的关系之一。软件工程的一条重要原则是尽量减少耦合，在 组合和继承都能均可适用的情况下，应该优先考虑使用组合。组合的意思是将一种类型 以成员变量方式嵌入相关类型中。组合有如下优点：
1）在不影响调用代码的同时也更灵活。
2）编译期绝缘性好，编译时间也能缩短。
3）代码不可预测程度降低（有些类不适合作为基类）。
5、尽可能局部地声明变量，这通常是在程序具备了足够的数据来初始化变量之后， 并紧接着首次使用该变量之前。 例外：
1）有时将变量从循环内提出到循环外是有益的。
2）由于常量不增加状态，因此本条对常量不适用。
6、尽量用异常来报告错误。与错误码相比，要尽量用异常来报告错误。对一些无法使用异常的错误，或者一些不属于错误的情况，可以用状态码（status code，例如：返回码，errno）来报告。如果不可能或不需要从错误中恢复，那么可以使用其它方法，比如正常或非正常地终止程序。在 C++中，和用错误码来报告错误相比，用异常来报告错误具有许多明显的优势，所有这些都使得编出来的代码更健壮：
1）程序员不能无视异常：错误码的最糟糕的缺点就是在默认情况下它们会被忽略； 即使是给予错误码微不足道的关注，都必须显式地编写代码，以接受错误并做出反应。程序员因为偶然（或因为懒惰）而忘记关注错误码是很平常的事。这使得代码复查变得更困难。
2）异常会自动传递：默认情况下错误码不会跨作用域传递；为了把一个低层的错误 码通知高层的调用函数，程序员必须在中间层的代码中显式地手工编写代码以传递 该错误。异常会自动地跨作用域传递，直到被处理为止。
3）异常处理从主控制流中去除了错误处理及恢复：错误码的检测及处理，一旦要写的话，就必须夹杂在主控制流中（并使之变得难以理解）。这使得主控制流以及错误 处理的代码都更难以理解和维护。异常处理很自然地把错误检测及恢复移到醒目的 catch 代码块中，即它使错误处理既醒目，又易于使用，而不是纠缠在主控制流中。
七、在 可测性上
1、在同一项目组或产品组内，要有一套统一的为集成测试与系统联调准备的调测开关及相应打印函数，并且要有详细的说明。
2、在同一项目组或产品组内，调测打印出的信息串的格式要有统一的形式。信息串中至少要有所在模块名（或源文件名）及行号。
3、编程的同时要为单元测试选择恰当的测试点，并仔细构造测试代码、测试用例，同时给出明确的注释说明。测试代码部分应作为（模块中的）一个子模块，以方便测试代码在模块中的安装与拆卸（通过调测开关）。
4、在进行集成测试/系统联调之前，要构造好测试环境、测试项目及测试用例，同时仔细分析并优化测试用例，以提高测试效率。
5、使用断言来发现软件问题，提高代码可测性。
6、用断言来检查程序正常运行时不应发生但在调测时有可能发生的非法情况。
7、不能用断言来检查最终产品肯定会出现且必须处理的错误情况。
8、对较复杂的断言加上明确的注释
9、用断言确认函数的参数。
10、用断言保证没有定义的特性或功能不被使用。
11、用断言对程序开发环境（OS/Compiler/Hardware）的假设进行检查。
12、正式软件产品中应把断言及其它调测代码去掉（即把有关的调测开关关掉）。
13、在软件系统中设置与取消有关测试手段，不能对软件实现的功能等产生影响。
14、用调测开关来切换软件的DEBUG版和正式版，而不要同时存在正式版本和DEBUG版本的不同源文件，以减少维护的难度。
15、软件的DEBUG版本和发行版本应该统一维护，不允许分家，并且要时刻注意保证两个版本在实现功能上的一致性。
16、在编写代码之前，应预先设计好程序调试与测试的方法和手段，并设计好各种调测开关及相应测试代码如打印函数等。
17、调测开关应分为不同级别和类型。
18、编写防错程序，然后在处理错误之后可用断言宣布发生错误。
八、在 代码编辑、编译、审查 上
1、打开编译器的所有告警开关对程序进行编译。
2、在产品软件（项目组）中，要统一编译开关选项。
3、通过代码走读及审查方式对代码进行检查。
4、测试部测试产品之前，应对代码进行抽查及评审。
5、编写代码时要注意随时保存，并定期备份，防止由于断电、硬盘损坏等原因造成代码丢失。
6、同产品软件（项目组）内，最好使用相同的编辑器，并使用相同的设置选项。
7、要小心地使用编辑器提供的块拷贝功能编程。
8、合理地设计软件系统目录，方便开发人员使用。
9、某些语句经编译后产生告警，但如果你认为它是正确的，那么应通过某种手段去掉告警信息。
10、使用代码检查工具（如C语言用PC-Lint）对源程序检查。
11、使用软件工具（如 LogiSCOPE）进行代码审查。
九、在代码测试及维护上
1、单元测试要求至少达到语句覆盖。
2、单元测试开始要跟踪每一条语句，并观察数据流及变量的变化。
3、清理、整理或优化后的代码要经过审查及测试。
4、代码版本升级要经过严格测试。
5、使用工具软件对代码版本进行维护。
6、正式版本上软件的任何修改都应有详细的文档记录。
7、发现错误立即修改，并且要记录下来。
8、关键的代码在汇编级跟踪。
9、仔细设计并分析测试用例，使测试用例覆盖尽可能多的情况，以提高测试用例的效率。
10、尽可能模拟出程序的各种出错情况，对出错处理代码进行充分的测试。
11、仔细测试代码处理数据、变量的边界情况。
12、保留测试信息，以便分析、总结经验及进行更充分的测试。
13、不应通过“试”来解决问题，应寻找问题的根本原因。
14、对自动消失的错误进行分析，搞清楚错误是如何消失的。
15、修改错误不仅要治表，更要治本。
16、测试时应设法使很少发生的事件经常发生。
17、明确模块或函数处理哪些事件，并使它们经常发生。
18、 坚持在编码阶段就对代码进行彻底的单元测试，不要等以后的测试工作来发现问题。
19、去除代码运行的随机性（如去掉无用的数据、代码及尽可能防止并注意函数中的“内部寄存器”等），让函数运行的结果可预测，并使出现的错误可再现。
十、个人编码模板
1、代码的可读性至上
代码要能可阅读和可理解，就需要格式化成一致的方式。对函数和变量的命名应有意义，注释的表达应该简洁而准确。并且，准确地记录代码中所有棘手的部分是十分重要的。你必须清楚软件程序为什么能工作以及为什么能在所有可能的情况下顺利工作的原因。
2、 遵循正确的命名约定
当需要给类、函数和变量命名时，需要遵循以下指南：
1)、确保特定类名的第一个字母大写；
2)、使用大小写分离多个单词的命名；
3)、大写常数名，并使用下划线分离单词；
4)、确保特定功能和变量名的第一个字母小写；
5)、注意正确使用缩写。例如，用max而不用maximum。
3、必要时可使用空格
虽然空格对编译器是没有意义的，但是可用于提高代码的可读性。举个例子，你可以在函数间留三个空行。你还可以在函数内使用单独的空行用于分离关键的代码段。
4、确保代码有一定的可维护性
我们需要确保写出来的代码，换成另一个程序员来调整功能、修复bug，也是明确易懂的。要将函数中关键值用常量来标记，这样我们就可以随时根据需要来改变这些常量值。总而言之，代码必须坚固，能够处理任何类型的输入，然后在不崩溃的前提下，提供预期结果。
5、注释必须易于理解
注释应该是有意义的，能够清晰地解释所有关于软件程序的内容。注释的数量多少无所谓，质量才是关键。你需要使用/ 注释 /的风格来写注释，以确保位于每个源文件的顶部。此外，你也可以选择在注释中包括你的名字，编写代码的日期，以及简明扼要地说明程序的实际用途。不过，你可以选择省略一些功能明显的注释。你需要遵循的行内注释格式为//注释。
6、正确使用函数
每一个函数所包含的代码片段，必须既短又能够完成特定的任务。不妨将函数当作是“黑盒子”——独立，又可以有效处理任何类型的输入。不要忘记这样一条经验规则——即所谓的“Ten Line Rule”，也就是说，一个函数，通常说来，如果超过10行，那就需要以最精炼的方式去简化。并且，任何重复性的代码片段都应该被设置为一个单独的函数。上述做法不但可缩短程序的长度，还能大大提高其可读性。
7、整体的代码缩进
缩进在软件程序的流程控制上起着至关重要的作用。每一个新的while、for、if语句，以及switch结构，都需要缩进代码。这也可用于一行语句中括号已被省去的情况。例如，假设有if语句，那么相应else语句必须一齐缩进。
转自百度
Java编程风格
1.1 排版
1.1.1 规则
规则1 程序块要采用缩进风格编写，缩进的空格数为4个，不允许使用TAB缩进。
说明：缩进使程序更易阅读，使用空格缩进可以适应不同操作系统与不同开发工具。
规则2 分界符（如大括号‘{’和‘}’）应各独占一行，同时与引用它们的语句左对齐。在函数体的开始、类和接口的定义、以及if、for、do、while、switch、case语句中的程序或者static、,synchronized等语句块中都要采用如上的缩进方式。
示例:
if (a>b)
{
doStart();
}
规则3 较长的语句、表达式或参数（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读。
示例：
if(logger.isDebugEnabled())
{
logger.debug(“Session destroyed,call-id”
+event.getSession().getCallId());
}
规则4 不允许把多个短语句写在一行中，即一行只写一条语句
说明：阅读代码更加清晰
示例：如下例子不符合规范。
Objecto = new Object(); Object b = null;
规则5 if, for, do, while, case, switch, default 等语句自占一行，且if, for, do, while,switch等语句的执行语句无论多少都要加括号{},case 的执行语句中如果定义变量必须加括号{}。
说明：阅读代码更加清晰，减少错误产生
示例：
if (a>b)
{
doStart();
}
case x:
1
{
inti = 9;
}
规则6 相对独立的程序块之间、变量说明之后必须加空行。
说明:阅读代码更加清晰
示例：
if(a > b)
{
doStart();
}
//此处是空行
return;
规则7 在两个以上的关键字、变量、常量进行对等操作时，它们之间的操作符之前、之后或者前后要加空格；进行非对等操作时，如果是关系密切的立即操作符（如.），后不应加空格。
说明：阅读代码更加清晰
示例：
if (a == b)
{
objectA.doStart();
}
a *= 2;
1.1.2 建议
建议1 类属性和类方法不要交叉放置，不同存取范围的属性或者方法也尽量不要交叉放置。
格式：
类定义
{
类的公有属性定义
类的保护属性定义
类的私有属性定义
类的公有方法定义
类的保护方法定义
类的私有方法定义
}
建议2 修饰词按照指定顺序书写：[访问权限][static][final] 。
示例：
publicstatic final String str = “abc”;
1.2 注释
1.2.1 规则
规则1 源程序注释量必须在30％以上。
说明：由于每个文件的代码注释不一定都可以达到30%，建议以一个系统内部模块作为单位进行检查
规则2 包的注释：写入一个名为 package.html的HTML格式的说明文件放入包所在路径。包的注释内容：简述本包的作用、详细描述本包的内容、产品模块名称和版本、公司版权。
说明：方便JavaDoc收集，方便对包的了解
示例：
com/huawei/iin/websmap/comm/package.html
一句话简述。
详细描述。
产品模块名称和版本
公司版权信息
示例：
为WEBSMAP 提供通信类，上层业务使用本包的通信类与SMP-B 进行通信。
详细描述。。。。。。。。
IINV100R001 WEBSMAP
(C)版权所有 2000-2001 华为技术有限公司
规则3 类和接口的注释放在class 或者 interface 关键字之前，import 关键字之后。注释主要是一句话功能简述与功能详细描述。类注释使用“/* /”注释方式
说明：方便JavaDoc收集,没有import可放在package之后。注释可根据需要列出：作者、内容、功能、与其它类的关系等。功能详细描述部分说明该类或者接口的功能、作用、使用方法和注意事项，每次修改后增加作者和更新版本号和日期，@since 表示从那个版本开始就有这个类或者接口，@deprecated 表示不建议使用该类或者接口。
/**
* 〈一句话功能简述〉
* 〈功能详细描述〉
* @author [作者]（必须）
* @see [相关类/方法]（可选）
* @since [产品/模块版本] （必须）
* @deprecated （可选）
*/
示例：
packagecom.huawei.iin.logwebsmap.comm;
importjava.util.*;
/**
* LogManager 类集中控制对日志读写的操作。
* 全部为静态变量和静态方法，对外提供统一接口。分配对应日志类型的读写器，
* 读取或写入符合条件的日志纪录。
* @author 张三，李四，王五
* @see LogIteraotor
* @see BasicLog
* @since CommonLog1.0
*/
publicclass LogManager
规则4 类属性(成员变量)、公有和保护方法注释：写在类属性、公有和保护方法上面，注释方式为“/* /”.
示例：
/**
* 注释内容
*/
privateString logType;
/**
* 注释内容
*/
publicvoid write()
规则5 公有和保护方法注释内容：列出方法的一句话功能简述、功能详细描述、输入参数、输出参数、返回值、异常等。
格式：
/**
* 〈一句话功能简述〉
* 〈功能详细描述〉
* @param [参数1] [参数1说明]
* @param [参数2] [参数2说明]
* @return [返回类型说明]
* @exception/throws [异常类型] [异常说明]
* @see [类、类#方法、类#成员]
* @since [起始版本]
* @deprecated
*/
说明：@since 表示从那个版本开始就有这个方法，如果是最初版本就存在的方法无需说明；@exception或throws 列出可能仍出的异常；@deprecated 表示不建议使用该方法。
示例：
/**
* 根据日志类型和时间读取日志。
* 分配对应日志类型的LogReader， 指定类型、查询时间段、条件和反复器缓冲数，
* 读取日志记录。查询条件为null或0的表示没有限制，反复器缓冲数为0读不到日志。
* 查询时间为左包含原则，即[startTime, endTime) 。
* @param logTypeName 日志类型名（在配置文件中定义的）
* @param startTime 查询日志的开始时间
* @param endTime 查询日志的结束时间
* @param logLevel 查询日志的级别
*@param userName 查询该用户的日志
* @param bufferNum 日志反复器缓冲记录数
* @return 结果集，日志反复器
* @since 1.2
*/
public static LogIterator read(StringlogType, Date startTime, Date endTime, intlogLevel, String userName, int bufferNum)
规则6 对于方法内部用throw语句抛出的异常，必须在方法的注释中标明，对于所调用的其他方法所抛出的异常，选择主要的在注释中说明。 对于非RuntimeException，即throws子句声明会抛出的异常，必须在方法的注释中标明。
说明：异常注释用@exception或@throws表示，在JavaDoc中两者等价，但推荐用@exception标注Runtime异常，@throws标注非Runtime异常。异常的注释必须说明该异常的含义及什么条件下抛出该异常。
规则7 注释应与其描述的代码相近，对代码的注释应放在其上方，并与其上面的代码用空行隔开，注释与所描述内容进行同样的缩排。
说明：可使程序排版整齐，并方便注释的阅读与理解。
示例：
/*
* 注释
*/
publicvoid example2( )
{
// 注释
CodeBlock One
// 注释
CodeBlock Two
12
}
/*
* 注释
*/
publicvoid example( )
{
// 注释
CodeBlock One
// 注释
CodeBlock Two
12
}
规则8 对于switch语句下的case语句，必须在每个case分支结束前加上break语句。
说明：break才能真正表示该switch执行结束，不然可能会进入该case以后的分支。至于语法上合法的场景“一个case后进入下一个case处理”，应该在编码设计上就避免。
规则9 修改代码同时修改相应的注释，以保证注释与代码的一致性。不再有用的注释要删除。
规则10 注释的内容要清楚、明了，含义准确，防止注释二义性。
说明：错误的注释不但无益反而有害。
规则11 避免在注释中使用缩写，特别是不常用缩写。
说明：在使用缩写时或之前，应对缩写进行必要的说明。
规则12 对重载父类的方法必须进行@Override声明(5.0+)
说明：可清楚说明此方法是重载父类的方法，保证重载父类的方法时不会因为单词写错而造成错误(写错方法名或者参数个数，类型都会编译无法通过)
示例：
@Override
public voiddoRequest(SipServletRequest req) throws ServletException,
IOException
1.2.2 建议
建议1 避免在一行代码或表达式的中间插入注释。
说明：除非必要，不应在代码或表达中间插入注释，否则容易使代码可理解性变差。
建议2 在代码的功能、意图层次上进行注释，提供有用、额外的信息。
说明：注释的目的是解释代码的目的、功能和采用的方法，提供代码以外的信息，帮助读者理解代码，防止没必要的重复注释信息。
示例：如下注释意义不大。
// 如果receiveFlag 为真
if(receiveFlag)
而如下的注释则给出了额外有用的信息。
//如果从连结收到消息
if(receiveFlag)
建议3 对关键变量的定义和分支语句（条件分支、循环语句等）必须编写注释。
说明：这些语句往往是程序实现某一特定功能的关键，对于维护人员来说，良好的注释帮助更好的理解程序，有时甚至优于看设计文档。
建议4 注释应考虑程序易读及外观排版的因素，使用的语言若是中、英兼有的，建议多使用中文，除非能用非常流利准确的英文表达。中文注释中需使用中文标点。方法和类描述的第一句话尽量使用简洁明了的话概括一下功能，然后加以句号。接下来的部分可以详细描述。
说明：注释语言不统一，影响程序易读性和外观排版，出于对维护人员的考虑，建议使用中文。JavaDoc工具收集简介的时候使用选取第一句话。
建议5 方法内的单行注释使用 //。
说明：调试程序的时候可以方便的使用/* 。。。*/ 注释掉一长段程序。
建议6 一些复杂的代码需要说明。
示例：这里主要是对闰年算法的说明。
//1. 如果能被4整除，是闰年；
//2. 如果能被100整除，不是闰年；
//3. 如果能被400整除，是闰年。
建议7 使用Html标签使JavaDoc生成更加美观。
示例：
/**
* Returns a hash code for this string. Thehash code for a
* String objectis computed as
*
* s[0]*31^(n-1) + s[1]*31^(n-2) + ... +s[n-1]
*
* using intarithmetic, where s[i] is the
* ith character of thestring, n is the length * of
* the string, and^ indicates exponentiation.
* (The hash value of the empty string iszero.)
*
* @return a hash code value for this object.
*/
public int hashCode()
生成后的JavaDoc
图1 生成后的JavaDoc
1.3 命名
1.3.1 规则
规则1 类名和接口使用类意义完整的英文描述，每个英文单词的首字母使用大写、其余字母使用小写的大小写混合法。
示例：OrderInformation,CustomerList, LogManager, LogConfig, SmpTransaction
规则2 方法名使用类意义完整的英文描述：第一个单词的字母使用小写、剩余单词首字母大写其余字母小写的大小写混合法。
示例：
privatevoid calculateRate();
publicvoid addNewOrder();
规则3 方法中，存取属性的方法采用setter 和 getter方法，动作方法采用动词和动宾结构。
格式：
get + 非布尔属性名()
is + 布尔属性名()
set + 属性名()
动词()
动词 + 宾语()
示例：
publicString getType();
publicboolean isFinished();
publicvoid setVisible(boolean);
publicvoid show();
publicvoid addKeyListener(Listener);
规则4 属性名使用意义完整的英文描述，第一个单词的字母使用小写，剩余单词首字母大写其余字母小写的大小写混合法。属性名不能与方法名相同。
示例：
privatecustomerName;
privateorderNumber;
privatesmpSession;
规则5 常量名使用全大写的英文描述，英文单词之间用下划线分隔开，并且使用 static final修饰。
示例：
publicstatic final int MAX_VALUE = 1000;
publicstatic final String DEFAULT_START_DATE = “2001-12-08”;
1.3.2 建议
建议1 包名采用域后缀倒置的加上自定义的包名，采用小写字母，都应该以com.huawei开头(不包括一些特殊原因)。在部门内部应该规划好包名的范围，防止产生冲突。部门内部产品使用部门的名称加上模块名称。产品线的产品使用产品的名称加上模块的名称。
说明：除特殊原因包结构都必须以com.huawei开头，如果因为OEM合作等关系，可以不做要求。
格式：
com.huawei.产品名.模块名称
示例：
融合WEBSMAP包名 com.huawei.iin.websmap
建议2 通过对函数或过程、变量、结构等正确的命名以及合理地组织代码的结构，使代码成为自注释的。
说明：清晰准确的函数、变量等的命名，可增加代码可读性，并减少不必要的注释。
建议3 常用组件类的命名以组件名加上组件类型名结尾。
示例：
Application 类型的，命名以App 结尾——MainApp
Frame 类型的，命名以Frame 结尾——TopoFrame
Panel 类型的，建议命名以Panel结尾——CreateCircuitPanel
Bean 类型的，建议命名以Bean 结尾——DataAccessBean
EJB 类型的，建议命名以EJB 结尾——DBProxyEJB
Applet 类型的，建议命名以Applet 结尾——PictureShowApplet
建议4 如果函数名超过15 个字母，可采用以去掉元音字母的方法或者以行业内约定俗成的缩写方式缩写函数名。
示例：
getCustomerInformation() 改为 getCustomerInfo()
建议5 准确地确定成员函数的存取控制符号:只是该类内部调用的函数使用 private 属性，继承类可以使用的使用protected属性，同包类可以调用的使用默认属性(不加属性控制符号)，对外公开的函数使用public属性
示例：
protected void getUserName()
{
。。。。。。
}
private void calculateRate()
{
。。。。。。
}
建议6 含有集合意义的属性命名，尽量包含其复数的意义。
示例：
customers, orderItems
1.4 编码
1.4.1 规则
规则1 数据库操作、IO操作等需要使用结束close()的对象必须在try -catch-finally 的finally中close()，如果有多个IO对象需要close()，需要分别对每个对象的close()方法进行try-catch,防止一个IO对象关闭失败其他IO对象都未关闭。
示例：
try
{
// … …
}
catch(IOExceptionioe)
{
//… …
}
finally
{
try
{
out.close();
}
catch (IOException ioe)
{
//… …
}
try
{
in.close();
}
catch (IOException ioe)
{
//… …
}
}
规则2 系统非正常运行产生的异常捕获后，如果不对该异常进行处理，则应该记录日志。
说明：此规则指通常的系统非正常运行产生的异常，不包括一些基于异常的设计。若有特殊原因必须用注释加以说明。
示例：
try
{
//…. …
}
catch(IOException ioe)
{
logger.error(ioe);
}
规则3 自己抛出的异常必须要填写详细的描述信息。
说明：便于问题定位。
示例：
thrownew IOException(“Writing dataerror! Data: ” + data.toString());
规则4 运行时异常使用RuntimeException的子类来表示，不用在可能抛出异常的方法声明上加throws子句。非运行期异常是从Exception继承而来的，必须在方法声明上加throws子句。
说明：
非运行期异常是由外界运行环境决定异常抛出条件的异常，例如文件操作，可能受权限、磁盘空间大小的影响而失败，这种异常是程序本身无法避免的，需要调用者明确考虑该异常出现时该如何处理方法，因此非运行期异常必须有throws子句标出，不标出或者调用者不捕获该类型异常都会导致编译失败，从而防止程序员本身疏忽。
运行期异常是程序在运行过程中本身考虑不周导致的异常，例如传入错误的参数等。抛出运行期异常的目的是防止异常扩散，导致定位困难。因此在做异常体系设计时要根据错误的性质合理选择自定义异常的继承关系。
还有一种异常是Error 继承而来的，这种异常由虚拟机自己维护，表示发生了致命错误，程序无法继续运行例如内存不足。我们自己的程序不应该捕获这种异常，并且也不应该创建该种类型的异常。
规则5 在程序中使用异常处理还是使用错误返回码处理，根据是否有利于程序结构来确定，并且异常和错误码不应该混合使用，推荐使用异常。
说明：
一个系统或者模块应该统一规划异常类型和返回码的含义。
但是不能用异常来做一般流程处理的方式，不要过多地使用异常，异常的处理效率比条件分支低，而且异常的跳转流程难以预测。
注意：Java 5.0 程序内部的错误码可以使用枚举来表示。
规则6 注意运算符的优先级，并用括号明确表达式的操作顺序，避免使用默认优先级。
说明：防止阅读程序时产生误解，防止因默认的优先级与设计思想不符而导致程序出错。
示例：
下列语句中的表达式
word= (high << 8) | low (1)
if((a | b) && (a & c)) (2)
if((a | b) < (c & d)) (3)
如果书写为
high<< 8 | low
a | b&& a & c
a | b< c & d
（1）（2）虽然不会出错，但语句不易理解；（3）造成了判断条件出错。
规则7 避免使用不易理解的数字，用有意义的标识来替代。涉及物理状态或者含有物理意义的常量，不应直接使用数字，必须用有意义的静态变量或者枚举来代替。使用异常来表示方法执行错误，而不是使用C++的错误返回码方式。
示例：如下的程序可读性差。
if(state == 0)
{
state = 1;
… // program code
}
应改为如下形式：
privatefinal static int TRUNK_IDLE = 0;
privatefinal static int TRUNK_BUSY = 1;
privatefinal static int TRUNK_UNKNOWN = -1;
if(state == TRUNK_IDLE)
{
state = TRUNK_BUSY;
… // program code
}
注意：Java5.0 下建议使用枚举来表示。
异常：
publicvoid function()
{
…
throw new RuntimeException(“。。。”);
}
规则8 数组声明的时候使用 int[] index ，而不要使用 int index[] 。
说明：使用int index[] 格式使程序的可读性较差，int [] index 表示声明了一个int数组(int [])叫做index
示例：
如下程序可读性差：
publicint getIndex()[]
{
….
}
如下程序可读性好：
publicint[] getIndex()
{
….
}
规则9 不要使用 System.out 与 System.err 进行控制台打印，应该使用工具类(如：日志工具)进行统一记录或者打印。
说明：代码发布的时候可以统一关闭控制台打印，代码调试的时候又可以打开控制台打印，方便调试。
规则10 用调测开关来切换软件的DEBUG版和正式版，而不要同时存在正式版本和DEBUG版本的不同源文件，以减少维护的难度。
转自原文：https://blog.csdn.net/qq_41582897/article/details/82284842
关于个人编码模板：
1 程序的版式
1.1 程序块要采用缩进的风格编写缩进的，缩进的空格数为四个。
1.2 缩进或者对齐只使用空格键，不使用Tab键。
1.3 相对独立的程序块之间、变量说明之后必须加空行。
以下情况应该是用空行分开：
1）函数之间应该用空行分开；
2）变量声明应尽可能靠近第一次使用处，避免一次性声明一组没有马上使用的变量；
3）用空行将代码按照逻辑片断划分；
4）每个类声明之后应该加入空格同其他代码分开。
1.4较长的语句（ >80 字符）要分成多行书写。
以下情况应分多行书写：
1）长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行
要进行适当的缩进，使排版整齐，语句可读。
2）若函数或过程中的参数较长，则要进行适当的划分。
3）循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分，长表达式
要在低优先级操作符处划分新行，操作符放在新行之首。
1.5 代码行之内应该留有适当的空格（采用这种松散方式编写代码的目的是使代码更加清晰。）
2 注释
2.1 * 文件描述 （Description）：描述此类的作用；
* 作者 （Author）：创建者或者修改者名；
* 版本 （Version）：创建或者修复时的编号，需要自行在bug管理系统中创建bug 号，使用bug号进行命名（若无bug管理工具的临时办法：如无bug号，从1开始，修改时依次增加）
* 日期（Date）：创建或者修改时的日期，使用“-”进行年月日分割；
* 记录（Record）：创建或者修改的工作内容描述；
2.2 关键点注释
应该包含如下信息：
* 一些程序关键的地方 ；
* 一些程序不易读的地方 ；
* 编写代码过程中遇到问题的地方 ；
* 需要提示读者的地方；
3 标识符命名
3.1 命名尽量使用英文单词，力求简单清楚，避免使用引起的误解的词汇和模糊的缩写，使人产生误解。
3.2 常量、宏和模板名采用全大写的方式，每个单词间用下划线分隔。
3.3 对于变量命名，禁止取单个字符（如i、j、k…），建议除了要有具体含义外，还能表明其变量类型、数据类型等，但i、j、k做局部循环变量是允许的。
说明：
变量，尤其是局部变量，如果用单个字符表示，很容易敲错（如 i 写成 j），而编译
时又检查不出来，有可能为了这个小小的错误而花费大量的查错时间。
6.4 不要使用数字或比较奇怪的字符来定义标识符。
3.5 函数名以大写字母开头，采用谓-宾结构（动-名），且应反映函数执行什么操作以及返回什么内容。
3.6 类、结构、联合、枚举的命名须分别以C、S、U、E开头，其他部分遵从一般变量命名规范。
4 变量、结构
4.1 尽量少使用全局变量，尽量去掉没必要的公共变量。
说明：
公共变量是增大模块间耦合的原因之一，故应减少没必要的公共变量以降低模块间的耦合度。
4.2 变量，特别是指指针变量，被创建之后应当及时把它们初始化，以防止把未被初始化的变量当成右值使用。
说明：在 C/C++中引用未经赋值的指针，经常会引起系统崩溃
4.3 仔细设计结构中元素的布局与排列顺序，使结构容易理解、节省占用空间，并减少引起的误用现象。
5 可读性
5.1 用括号明确表达式的操作顺序，避免使用默认优先级。
5.2 不要编写太复杂、多用途的复合表达式。
5.3 涉及物理状态或者含有物理意义的常量，避免直接使用数字，必须用有意义的枚举或常量来代替。
5.4 禁止使用难以理解，容易产生歧义的语句。
部分原文转自：https://blog.csdn.net/hxy499/article/details/61930532
部分原文转自：https://blog.csdn.net/qq_41582897/article/details/82284842
部分原文转自：https://blog.csdn.net/zhaoxqzz/article/details/82227812