java程序员都有哪些应该注意的编码规范?

Posted 2023-04-19

Java编码规范:　尽量使用完整的英文描述符采用适用于相关领域的术语采用大小写混合使名字可读尽量少用缩写，但如果用了，必须符合整个工程中的统一定义避免使用长的名字（小于15个字母为正常选择）避免使用类似的名字，或者仅仅是大小写不同的名字避免使用下划线（除静态常量等）标识符类型说明包（Package）的命名Package的名字应该采用完整的英文描述符，都是由一个小写单词组成。并且包名的前缀总是一个顶级域名
，通常是com、edu、gov、mil、net、org等；如：com.yjhmily.test类（Class）的命名类名应该是个一名词，采用大小写混合的方式，每个单词的首字母大写。尽量保证类名简洁而富于描述。 参考技术A 一、规范存在的意义
应用编码规范对于软件本身和软件开发人员而言尤为重要，有以下几个原因：
1、好的编码规范可以尽可能的减少一个软件的维护成本 , 并且几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护；
2、好的编码规范可以改善软件的可读性，可以让开发人员尽快而彻底地理解新的代码；
3、好的编码规范可以最大限度的提高团队开发的合作效率；
4、长期的规范性编码还可以让开发人员养成好的编码习惯，甚至锻炼出更加严谨的思维；
二、命名规范
1、一般概念
1、尽量使用完整的英文描述符
2、采用适用于相关领域的术语
3、采用大小写混合使名字可读
4、尽量少用缩写，但如果用了，必须符合整个工程中的统一定义
5、避免使用长的名字（小于 15 个字母为正常选择）
6、避免使用类似的名字，或者仅仅是大小写不同的名字
7、避免使用下划线（除静态常量等）
2、标识符类型说明
1、包（ Package ）的命名
Package 的名字应该采用完整的英文描述符，都是由一个小写单词组成。并且包名的前缀总是一个顶级域名，
通常是 com、edu、gov、mil、net、org 等；
如： com.yjhmily.test
2、类（ Class ）的命名
类名应该是个一名词，采用大小写混合的方式，每个单词的首字母大写。尽量保证类名简洁而富于描述。
使用完整单词，避免缩写词 ( 除非工程内有统一缩写规范或该缩写词被更广泛使用，像 URL ， html)
如： FileDescription
3、接口（ Interface ）的命名
基本与 Class 的命名规范类似。在满足 Classd 命名规则的基础之上，保证开头第一个字母为 ”I”，
便于与普通的 Class区别开。其实现类名称取接口名的第二个字母到最后，且满足类名的命名规范；
如： IMenuEngine
4、枚举（ Enum ）的命名
基本与 Class 的命名规范类似。在满足 Classd 命名规则的基础之上，保证开头第一个字母为 ”E” ，
便于与普通的 Class区别开。
如： EUserRole
5、异常（ Exception ）的命名
异常（ Exception ） 通常采用字母 e 表示异常，对于自定义的异常类，其后缀必须为 Exception
如： BusinessException
6、方法（ Method ）的命名
方法名是一个动词，采用大小写混合的方式，第一个单词的首字母小写，其后单词的首字母大写。
方法名尽可能的描述出该方法的动作行为。返回类型为 Boolean 值的方法一般由“ is ”或“ has ”来开头
如： getCurrentUser() 、 addUser() 、 hasAuthority()
7、参数（ Param ）的命名
第一个单词的首字母小写，其后单词的首字母大写。参数量名不允许以下划线或美元符号开头，
虽然这在语法上是允许的。参数名应简短且富于描述。
如： public UserContext getLoginUser(String loginName);
8、常量字段 （ Constants ）的命名
静态常量字段（ static final ） 全部采用大写字母，单词之间用下划线分隔；
如： public static final Long FEEDBACK;
public static Long USER_STATUS;
三、注释规范
一个很好的可遵循的有关注释的经验法则是：
问问你自己，你如果从未见过这段代码，要在合理的时间内有效地明白这段代码，你需要一些什么信息？？？
1、一般概念
1、注释应该增加代码的清晰度
2、保持注释的简洁
3、在写代码之前或同时写注释
4、注释出为什么做了一些事，而不仅仅是做了什么
2、注释哪些部分
1、Java 文件：必须写明版权信息以及该文件的创建时间和作者；
2、类：类的目的、即类所完成的功能，以及该类创建的时间和作者名称；多人一次编辑或修改同一个类时，
应在作者名称处出现多人的名称；
3、接口： 在满足类注释的基础之上，接口注释应该包含设置接口的目的、它应如何被使用以及如何不被使用。
在接口注释清楚的前提下对应的实现类可以不加注释；
4、方法注释： 对于设置 (Set 方法 ) 与获取 (Get 方法 ) 成员的方法，在成员变量已有说明的情况下，
可以不加注释；普通成员方法要求说明完成什么功能，参数含义是什么且返回值什么；另外方法的创建
时间必须注释清楚，为将来的维护和阅读提供宝贵线索；
5、方法内部注释： 控制结构，代码做了些什么以及为什么这样做，处理顺序等，特别是复杂的逻辑处理部分，
要尽可能的给出详细的注释；
6、参数： 参数含义、及其它任何约束或前提条件；
7、属性： 字段描述；
8、局部 ( 中间 ) 变量： 无特别意义的情况下不加注释；
3、注释格式
遵循工程规定的统一注释格式，一般情况下会以 codetemplates.xml 格式的文件导入 IDE(Eclipse)
或者用Eclipse默认的；
四、代码格式规范
遵循工程规定的统一代码格式，一般情况下直接使用 IDE(Eclipse) 自带的默认代码格式对代码进行格式化；
五、其他规范
JSP 文件命名
采用完整的英文描述说明 JSP 所完成的功能，尽可能包括一个生动的动词，第一个字母小写，
如： viewMessage.jsp 、editUser.jsp 等。
六、工程特有命名规范
1、持久层
1、 Hibernate 映射文件及实体
与数据库表名称完全对应；
如： Advertisement.hbm.xml 、 Advertisement.java
2、数据访问 DAO
DAO 接口和实现类名称必须完全符合正常接口和实现类的命名规则，且最后以 ”DAO” 结尾
DAO 内的数据访问方法必须足够抽象的描述出对数据库的基本 CRUD 操作；
如： ICrossAdDAO( 接口 ) 、 CrossAdDAO( 实现类 )
3、各种操作数据库的 HQL 配置文件
HQL 文件的个数原则上与系统的 Services 层的服务个数相等，且以服务名称命名 HQL 文件；
如： resource.hbm.xml
2、服务层
1、服务接口和实现
服务接口和实现类必须完全符合正常接口和实现类的命名规则；以工程定义的服务名为主体，
并统一以 ”Serv” 结尾
如： IResourceServ( 服务接口 ) 、 ResourceServ( 接口实现类 )
2、服务接口方法
方法名是一个动词，采用大小写混合的方式，第一个单词的首字母小写，其后单词的首字母大写。
方法名尽可能的描述出该方法的动作行为。
返回类型为 Boolean 值：用“ is ”或“ has ”来开头
得到某数据： get+ 数据描述名词复数 + 数据类型；
得到所有数据： get+All+ 数据描述名词复数 + 数据类型；
通过 XXX 得到 / 查询某数据： get/query+ 数据描述名词复数 + 数据类型 +By+ 条件；
添加某数据： save/add+ 数据描述名词 ()
更新某数据： save/update+ 数据描述名词；
删除某数据： delete/remove+ 数据描述名词；
3、业务对象
业务名称 +BO
4、查询参数对象
凡是继承 Abst***QuerySpec 的查询参数类全部满足以下规则：
Query+ 所要查询的数据描述名词 +Spec
作为参数传入时，参数名必须为：所要查询的数据描述名词 +Spec
如： QueryProgramSpec
3、MVC 层
1、Action 控制层
Action 类名：功能模块名称 +Action ；
Actoin 方法名称尽可能的描述出页面迁移的去向
如： LoginAction( 登录用 action) ， toWelcome( 转向欢迎页的 action 方法 )
2、资源文件
系统全局资源文件： globalMessages_+ 字符编码类型 +.properties
功能模块内部的资源文件： package.properties
4、Spring 配置文件
1、Action 相关配置文件
文件目录： WebRoot/WEB-INF/spring/action/ 功能模块名称 +_ApplicationContext.xml
2、Services 相关配置文件
文件目录： WebRoot/WEB-INF/spring/services/Services_ApplicationContext.xml
3、全局性配置文件
文件目录： WebRoot/WEB-INF/spring/工程名+_ApplicationContext.xml
5、JSP 文件
采用完整的英文描述说明 JSP 所完成的功能，尽可能包括一个生动的动词，第一个字母小写，
如： viewMessage.jsp 、editUser.jsp 等。 参考技术B

参考《阿里巴巴Java开发手册》

有经验的 Java SWT 程序员在迁移到 Swing 时应该注意哪些主要事项？

【中文标题】有经验的 Java SWT 程序员在迁移到 Swing 时应该注意哪些主要事项？

【英文标题】：What are the main things that an experienced Java SWT programmer should be aware of when moving to Swing?

【发布时间】：2011-10-03 07:36:54

【问题描述】：

可能遇到的主要差异是什么？应用程序设计有什么重大差异吗？线程模型？您构建 GUI 的方式是什么？ Swing 中没有 SWT 的哪些功能？

【问题讨论】：

ibm.com/developerworks/grid/library/os-swingswt 和其他谷歌返回的网站

我的主要建议：不要尖叫太多。 SWT 在过去 10 年中有所改进，而 Swing 则没有。

【参考方案1】：

从我在 Swing 和 SWT 之间的经验中得到的一些发现

Swing 的渲染速度有点慢（我的经验）并且使用更多的内存

原生外观可能只是部分（取决于选择的外观'n'feel）

大部分 Swing 组件都以某种方式实现了 MVC 模式

（因此您不必自己进行数据绑定）

可以对组件进行子类化，当您必须更改某些组件的行为时使用它（因此经常使用）

Swing 发送程序生成的事件

（我讨厌这种行为；]）

在 Swing 中，您不必调用 (a)syncExec() 方法

（您不必像在 SWT 中那样关心从哪个线程更新 GUI，但请务必阅读Swing threading policy (end of page) 和 Concurrency in Swing) Swing 真的很啰嗦（与 SWT 相比） 不再有 dispose() 方法；] Swing 在容器中具有标准布局管理器（请参阅 BorderLayout）并在基础上有 different layout managers（使用 MigLayout，它也适用于 Swing 和 SWT，没有竞争对手）

在创建组件实例时您不必知道您的父级，但您必须知道父级（容器）上的 .add(Component c) 方法

Swing 不依赖于平台

（不再针对每个平台和 x32/x64 进行多重构建）

Swing 有自己的错误

（与其他技术一样，这是不可避免的）

【讨论】：

Swing 组件不是线程安全的。所有的 GUI 更新都应该从 Event Dispatch Thread 完成。

只是补充一点，Swing 有更多的组件，并且比 SWT 更可定制（你可以制作更漂亮的 GUI）。

@Zemzela 这取决于意见，我相信（作为 SWT 和 Swing 程序员的经验）这两个 GUI 框架具有相同的表达可能性。但是在 SWT 中制作自己的组件有点困难是正确的（更多工作，更多代码），但在 SWT 中你不会经常这样做..

这不是真的 1) Swing 的渲染有点慢（我的经验）并且使用更多的内存 == 错误的建议 2) Swing 不是单线程 UI，因为 SWT == 错误的建议， Swing 是唯一且唯一的单线程输出到 GUI 3) Swing 真的很啰嗦 == ???? 4) 不再有 dispose() == 错误建议，dispose finalize

@mKordel 1) 内存蓝图比 SWT 高得多，可以证明，无论如何，渲染速度是我的看法（正如我所写的所有这些发现）2) 再次，我不知道如何正确地编写这个想法，但在 Swing 中，您不必调用 display.syncExec(Runnable thread)（或者我并不真正了解任何必要的用法）。我愿意接受任何更正确的描述 3) 意味着您必须编写比在 SWT 中更多的代码，因为 Swing 不使用位设置作为 SWT（SWT.CLOSE | SWT.OK | SWT.CANCEL 等）。