下载文档原格式
阿⾥JAVA开发规范,助你写出更⼲净整洁的代码⼀、命名风格1.【强制】类名使⽤UpperCamelCase 风格，必须遵从驼峰形式，但以下情形例外：DO / BO / DTO / VO / AO2.正例：MarcoPolo / UserDO / XmlService / TcpUdpDeal /TaPromotion3.反例：macroPolo / UserDo / XMLService / TCPUDPDeal /TAPromotion4.【强制】⽅法名、参数名、成员变量、局部变量都统⼀使⽤lowerCamelCase 风格，必须遵从驼峰形式。
5.正例：localValue / getHttpMessage() / inputUserId6.【强制】常量命名全部⼤写，单词间⽤下划线隔开，⼒求语义表达完整清楚，不要嫌名字长。
7.正例：MAX_STOCK_COUNT 反例：MAX_COUNT8.【强制】抽象类命名使⽤Abstract 或Base 开头；异常类命名使⽤Exception 结尾；测试类命名以它要测试的类的名称开始，以Test 结尾。
9.【强制】Model 类中布尔类型的变量，都不要加is，否则部分框架解析会引起序列化错误。
10.反例：定义为基本数据类型Boolean isDeleted；的属性，它的⽅法也是isDeleted()，RPC框架在反向解析的时候，“以为”对应的属性名称是deleted，导致属性获取不到，进⽽抛出异常。
11.【强制】对于Service 和DAO 类，基于SOA 的理念，暴露出来的服务⼀定是接⼝，内部的实现类⽤Impl 的后缀与接⼝区别。
正例：CacheManagerImpl 实现CacheManager 接⼝。
12.【推荐】为了达到代码⾃解释的⽬标，任何⾃定义编程元素在命名时，使⽤尽量完整的单词组合来表达其意。
正例：从远程仓库拉取代码的类命名为PullCodeFromRemoteRepository 反例：变量int a;的随意命名⽅式。
java开发规范(一)java命名规范1、变量、成员、方法名统一采用驼峰命名(lowerCamelCase),做到见语知其义例子：变量——用户数据(userList)、方法——getUserData(int type)等。
说明：正常变量定义使用驼峰命名,特殊的如DTO\VO\DO等除外。
2、类名的定义（1）普通类名采用大写字母开始;（2）抽象类采用Abstract或Base开头。
例子：普通类——class UserModel,抽象类——abstract class AbstractUserDefinition等。
3、常量、类型、接口、子类的定义（1）常量使用全大写且单词之间用"_“隔开; （2）boolean变量不能使用is开头;（3）接口尽量不要修饰符、子类紧跟接口追加Impl。
例子：常量——SORT_TYPE,布尔类型——flag,接口——UserService,实现类——UserServiceImpl等。
说明：常量不可组装,需要原子性定义,不能出现"KEY”+SORT_TYPE 这种内部出现。
4、包名、异常、枚举、方法名称的定义（1）包名一律采用小写; （2）异常都采用_Exception结尾; （3）枚举都是以Enum结尾;（4）方法名称——根据方法内容采用如插入insert-*。
例子：异常——UserException,包名——com.test,枚举——UserEnum,方法名称——insertUser等。
5、领域模型定义规范：主要是以VO\DTO\DO等结尾例子：用户数据——UserDTO等（1）数据对象：xxxDO,xxx 即为数据表名。
（2）数据传输对象：xxxDTO,xxx为业务领域相关的名称。
（3）展示对象：xxxVO,xxx一般为网页名称。
（4）POJO是DO/DTO/BO/VO的统称,禁止命名成xxxPOJO。
(二)代码格式规范1、括号代码要求左大括号前不换行、左大括号后换行、右大括号前换行、右大括号后还有else等代码则不换行；表示终止的右大括号后必须换行。
JAVA编程规范1.1 Java文件名与文件组织结构1.一个java源文件不应该超过2 000行。
2.在Java源文件中应该包含一个单一的公共类（class）或接口（interface），这个公共类或公共接口，应该是这个源文件的第一个类或接口。
3.一个Java源文件一般由下面的顺序构成：（1）文件注释头（2）包名（package）（3）引入（import）声明（4）类（class）或接口（interface）的声明部分1.2 Java文件注释头Java类文件注释头是用来描述该类功能及其特点，以及相关开发信息的，如该类的关联类（通常情况下不描述Java系统核心类如java.util.Vector, ng.Thread等）、开发公司或单位、版权、作者、代码审定人该类所支持的JDK版本、该类版本、开发日期、最后更改日期、修改人、复审人等信息，下面就是一个Java类文件注释头：/****************************************************************** 该类功能及其特点的描述（例如：该类是用来……）** 该类未被编译测试过。
** @see（与该类相关联的类）：(AnatherClass.java)*** 开发公司或单位：××软件有限公司研发中心** 版权：本文件版权归属××公司研发中心*** @author（作者）：必胜利** @since（该文件所支持的JDK版本）：Jdk1.3 或JDK1.42.在重点同时难以理解的地方另加注释。
方法体内的注释应该与其所描述的代码位于同一个层次上。
在一个块注释之前一般有一空白行用于做区分代码与注释的边界。
1.7 变量的声明初始化与放置1.7.1 变量声明1.在一般情况下我们建议每一行代码，只声明一个变量；2.如果变量名称较短并且又是同一数据类型同一结构类型，并且没有给变量初始化则可以在同一行声明；1.7.2 变量初始化尽量在变量声明的地方初始化，如果变量的初始化与有待于计算或处理后的值有关，则我们可以在取得这个值后对变量做初始化。
java 编程规范Java编程规范是为了促进Java代码的可读性、可维护性和可扩展性而制定的标准。
以下是一些常见的Java编程规范：一、命名规范1. 类名、接口名、枚举名首字母大写，采用驼峰命名法。
2. 变量名、方法名首字母小写，采用驼峰命名法。
3. 常量名全部大写，使用下划线分割单词。
4. 包名全部小写，使用点号分割单词。
二、代码格式1. 使用4个空格缩进。
2. 每行代码长度不超过80个字符。
3. 在二元运算符（如赋值、算术运算、逻辑运算）两侧添加空格。
4. 在逗号、冒号、分号之后添加空格。
5. 在左花括号之后和右花括号之前添加空格。
6. 在注释之前添加空格。
三、代码结构1. 类的成员按照作用域排列，先是静态成员，然后是实例成员。
2. 类的方法按照功能排列，先是构造方法，然后是其他方法。
3. 每个类只负责一个功能，遵循单一职责原则。
4. 使用适当的访问修饰符控制成员变量和方法的访问级别。
四、异常处理1. 不要捕获异常而不做任何处理，应该记录日志或者抛出更高级别的异常。
2. 不要将整个方法体放在try-catch块中，应该只捕获需要处理的异常。
3. 不要使用异常控制程序的流程，应该使用条件语句或者循环结构。
五、注释规范1. 使用Javadoc注释对类、方法、参数、返回值进行说明。
2. 在每个类的头部使用Javadoc注释描述该类的功能。
3. 使用内联注释对代码进行解释、补充和说明。
4. 注释应该清楚、简明、不冗余，遵循自然语言的习惯。
六、其他规范1. 避免使用魔法数值，应该使用常量或者枚举来表示。
2. 使用块注释对重要的代码块进行标注，方便阅读和查找。
3. 使用业界公认的缩写和术语，避免拼写错误和歧义。
4. 使用合适的数据结构和算法来解决问题，避免低效的代码。
以上仅是Java编程规范的一部分，具体的规范还需要根据具体的项目和团队来制定。
遵循编程规范可以提高代码质量和可维护性，提升团队的协作效率。
Java语言编程规范（华为公司）DKBA华为技术有限公司企业技术规范DKBAXXXX-2001.12代替（DKBA200106-003）Java语言编程规范2001-12-XX发布2001-12-XX实施华为技术有限公司发布VVVVVVV VVVVVVVVVVVX。
XVX.X VX.X VX.X VX.XVX.X 目次前言 .............................................................................. .. (3)1 范围112 规范性引用文件113 术语和定义114 排版规范124.1 规则121.*程序块要采用缩进风格编写，缩进12的空格数为4个。
122.*分界符（如大括号‘{’和‘}’）应各独占一行并且位于同一列，同时与引用它们的语句左对齐。
在函数体的开始、类和接口的定义、以及if、for、do、while、switch、case语句中的程序都要采用如上的缩进方式。
133.*较长的语句、表达式或参数（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读。
134.*不允许把多个短语句写在一行中，即一行只写一条语句5.*if, for, do, while, case,13switch, default 等语句自占一行，且if, for, do, while等语句的执行语句无论多少都要加括号{}。
6.*相对独立的程序块之间、变量说明13之后必须加空行。
7.*对齐只使用空格键，不使用TAB键。
14VVVVVVV VVVVVVVVVVVX。
XVX.X VX.X VX.X VX.XVX.X 8.*在两个以上的关键字、变量、常量14进行对等操作时，它们之间的操作符之前、之后或者前后要加空格；进行非对等操作时，如果是关系密切的立即操作符（如.），后不应加空格。
蓝凌JAVA 产品开发规范文档控制/Document Control 修改记录审阅人分发目录第一章、概述 (4)1.1、目的 (4)1.2、范围 (4)1.3、文档约定 (4)1.4、相关概念及词汇列表 (4)1.5、相关角色 (5)第二章、协作规范 (6)2.1、参与协作开发 (6)2.2、进行协作开发..........................错误！未定义书签。
2.3、相关规范 (6)第三章、设计规范 (8)3.1、JAVA存放位置 (8)3.2、页面存放位置 (9)3.3、配置文件存放位置 (9)3.4、业务代码位置 (10)3.5、数据库设计 (10)3.6、M ODEL规范 (11)3.7、D ESIGN配置规范 (11)3.8、JAVA类规范 (12)3.9、JSP界面规范 (13)3.10、PROPERTIES资源文件规范 (14)第四章、代码规范 (16)4.1、命名规范 (16)4.2、风格规范 (21)文档授权 (26)第一章、概述1.1、目的对于代码，首要要求是它必须正确，能够按照程序员的真实思想去运行；第二个的要求是代码必须清晰易懂，使别的程序员能够容易理解代码所进行的实际工作。
通过建立开发规范，形成开发小组编码约定，提高程序的可靠性、可读性、可修改性、可维护性、可继承性和一致性，可以保证程序代码的质量，继承软件开发成果，充分利用资源，使开发人员之间的工作成果可以共享。
1.2、范围1、项目组成员；2、蓝凌公司相关技术开发人员；3、其他经公司认可的必要知情的人员。
1.3、文档约定本文档采用MS Word2003软件编写，采用统一风格排版，正文风格为：五号中文宋体、五号英文Arial字体、行距1.5行；针对需要重点注意的段落，采用红色描色。
一般来说，各章内容相对独立，构成全文的有效组成部分。
1.4、相关概念及词汇列表【同步代码】在进行开发的过程中将本地的代码和SVN服务器的代码进行同步，在eclipse中的操作叫Synchronize whit Repository。
JAVA技术架构及开发规范文档一、概述二、技术架构1.三层架构基于业务功能的划分，将系统划分为表示层、业务逻辑层和数据持久层。
这样可以实现业务逻辑与表示层、数据持久层的解耦，提高代码的复用性和可维护性。
2.MVC模式使用MVC（Model-View-Controller）模式进行开发，将系统分为模型层、视图层和控制层，使各层之间的职责分明，提高代码的可维护性和可测试性。
3.面向对象设计原则遵循SOLID原则，尽量使用面向对象的设计和编程，其中包括单一职责原则、开闭原则、里式替换原则、接口隔离原则和依赖反转原则等。
三、开发规范1.命名规范采用驼峰命名法，变量名、方法名、类名等均应具有描述性，避免使用拼音或缩写。
2.代码风格代码应该具有良好的缩进和格式，增加代码的可读性。
要求适当添加注释，注释应说明代码的目的和使用注意事项。
3.异常处理合理处理异常，避免直接抛出异常，而是进行捕获和处理。
对于特定的业务异常，可以定义自定义异常类，并进行抛出。
4.注释规范需要对代码进行充分的注释，注释的风格应明确，注释应配合代码，解释代码的用途和作用。
5.单元测试开发过程中应进行单元测试，确保代码的正确性。
对于每个功能模块，编写相应的单元测试用例进行测试，覆盖率应尽量达到100%。
6.安全性对于涉及到的用户输入数据和敏感数据，应进行有效的验证和过滤，防止恶意注入和跨站脚本攻击等安全威胁。
7.日志规范所有的关键操作和错误信息都应记录到日志中，日志级别应根据实际需要进行配置。
8.数据库规范数据库表设计应符合第三范式，避免数据冗余和数据不一致。
使用参数化查询和预编译语句，提高数据库查询性能和安全性。
9.版本管理使用版本管理工具（如Git）进行代码管理，每个开发人员都应具备良好的版本管理和协同开发能力。
四、总结本文档主要介绍了JAVA技术架构及开发规范。
通过采用三层架构和MVC模式，可以实现代码的复用性和可维护性。
同时，遵循JAVA的面向对象设计原则，提高代码的可测试性和可扩展性。
java 代码规范Java代码规范是指在Java程序设计中遵循的一些规则和约定，旨在提高代码的可读性、可维护性和可移植性。
遵守代码规范可以帮助团队成员更好地理解和协作开发，提高代码的质量和可靠性。
本文将围绕Java代码规范展开讨论，包括命名规范、代码风格、注释规范、异常处理等方面的内容。
一、命名规范1.包名规范包名应该全小写，连接符可以使用小写字母和下划线，不推荐使用数字。
包名应该能够清晰地表达包所包含的内容，不要使用太长或者太短的包名。
2.类名规范类名应该采用驼峰命名法，首字母大写，类名应该能够清晰地表达类的用途，不要使用太长或者太短的类名。
如果类名由多个单词组成，应该遵循每个单词首字母大写的命名规范。
3.接口名规范接口名应该采用驼峰命名法，首字母大写，接口名应该能够清晰地表达接口的用途，不要使用太长或者太短的接口名。
如果接口名由多个单词组成，应该遵循每个单词首字母大写的命名规范。
4.变量名规范变量名应该采用驼峰命名法，首字母小写，变量名应该能够清晰地表达变量的用途，不要使用太长或者太短的变量名。
如果变量名由多个单词组成，应该遵循每个单词首字母小写的命名规范。
5.常量名规范常量名应该全大写，单词之间使用下划线分隔，常量名应该能够清晰地表达常量的用途，不要使用太长或者太短的常量名。
6.方法名规范方法名应该采用驼峰命名法，首字母小写，方法名应该能够清晰地表达方法的用途，不要使用太长或者太短的方法名。
如果方法名由多个单词组成，应该遵循每个单词首字母小写的命名规范。
二、代码风格1.缩进和空格缩进使用4个空格，不使用tab键。
在操作符前后使用空格，增强代码的可读性。
2.大括号的使用在类定义、方法定义、控制结构等的语句块后面使用大括号，增强代码的可读性。
3.代码行长度每行代码的长度不要超过80个字符，超过80个字符的代码应该使用换行符进行分割。
4.引号的使用字符串常量应该使用双引号，字符常量应该使用单引号。
JAVA开发设计规范JAVA开发设计规范是指在进行JAVA开发过程中，为了统一编码风格、提高代码可读性和可维护性而制定的一系列约定和规范。
本文将从命名规范、代码布局规范、注释规范、异常处理规范、编码规范等方面介绍JAVA开发设计规范。
1.命名规范变量、方法和类名应使用有意义的英文单词或缩写，遵循驼峰命名法。
-变量名应代表该变量的含义，且不使用无意义的单字母命名。
-方法名应清晰表达方法的功能和作用。
-类名应使用名词或名词短语，首字母大写。
2.代码布局规范-使用缩进方式使代码结构清晰可读。
-使用空行分隔不同的功能块。
-代码行长度应限制在80个字符之内，方便查看和打印。
3.注释规范-对于每个类、方法和成员变量，都应添加必要的注释说明其功能和用法。
-注释应该与代码同步更新，并保持准确性。
-注释应使用简洁明了的语言，不应包含冗余信息。
4.异常处理规范- 在代码中必须使用try-catch块处理可能抛出的受检异常。
- 不应使用catch(Exception e)的方式处理异常，在catch块中应提供相应的处理逻辑。
- 应避免在catch块中直接打印异常信息，而是应使用日志框架打印异常。
5.编码规范-尽量使用局部变量而不是全局变量。
-代码中不应包含硬编码的常量，应使用常量变量或配置文件存储。
-代码中应避免使用魔法数字，而使用有意义的命名常量代替。
-尽量避免使用复杂的表达式和语句，提高代码的可读性。
以上只是JAVA开发设计规范的一部分。
在实际开发过程中，还应根据团队的需求和实际情况进行适当的调整和补充。
良好的编码规范可以提高代码的可读性、可维护性和可扩展性，从而提高开发效率和代码质量。
同时，开发人员应定期进行代码审查和重构，以保证代码的质量和规范的执行。
Java 开发规范第1章绪论1.1 目的本规范的目的是使本组织能以标准的、规范的方式设计和编码。
通过建立编码规范，以使每个开发人员养成良好的编码风格和习惯；并以此形成开发小组编码约定，提高程序的可靠性、可读性、可修改性、可维护性和一致性等，增进团队间的交流，并保证软件产品的质量。
1.2 范围本规范适用于“Skyinn Group”及其下所有软件项目、产品等的设计、开发以及维护、升级等。
本规范使用于“Skyinn Group”的所有软件开发人员，在整个软件开发过程中必须遵循此规范。
1.3 版权声明本文档为共享文档，不限转载，但请保持本文档的完整性。
您可以修改本文档以符合您或组织、公司等之实际，但请在文档中保持对本文档的引用和说明。
未经本人授权，任何个人、组织或单位不得将本文档用于书面发表、转载、摘录等，亦不得用于其他商业行为。
本人及本组织不承担任何因使用、参考本文档等而导致的任何可能责任或连带责任。
1.4 参考资料《Java 编程指南》见RUP（Rational Unified Process）中文版。
《Java 技术手册》(Java in a Nutshell)《Sun Java 语言编码规范》(Java Code Conventions)《Effictive Java》《Java Pitfalls》《Java Rules》1.5 概述对于代码，首要要求是它必须正确，能够按照设计预定功能去运行；第二是要求代码必须清晰易懂，使自己和其他的程序员能够很容易地理解代码所执行的功能等。
然而，在实际开发中，每个程序员所写的代码却经常自成一套，很少统一，导致理解困难，影响团队的开发效率及系统的质量等。
因此，一份完整并被严格执行的开发规范是非常必须的，特别是对软件公司的开发团队而言。
此规范参考自业界标准编程规范并结合本人多年编程经验、习惯等而制定，在本人工作过的公司中都曾参考本文档而形成内部开发规范并执行。
现在将本文档共享之，希望能对各位有所帮助，并做引玉之砖，希望各位朋友将自己的经验等增补进去，对我们所热爱的软件业有所裨益。
最根本的原则：代码虽然是给机器运行的，但却是给人读的！运用常识。
当找不到任何规则或指导方针，当规则明显不能适用，当所有的方法都失效的时侯：运用常识并核实这些基本原则。
这条规则比其它所有规则都重要。
常识是必不可少。
当出现该情况时，应当及时收集并提交，以便对本规范进行修改。
共享第 6 页/共 6 页第2章代码组织与风格2.1 基本原则代码的组织和风格的基本原则是：便于自己的开发，易于与他人的交流。
因个人习惯和编辑器等可以设置和形成自己的风格，但必须前后一致，并符合本规范的基本要求和原则。
本章所涉及到的内容一般都可在Java 集成编辑环境中进行相应设置，也可由Ant 等调用checkstyle 等来进行自动规整。
开发工具经项目负责人调试后统一确定。
开发工具一经确定不允许集成任何非统一插件，若有需要，经项目负责人同意后统一为项目组成员添加。
开发工具的编码格式不允许修改。
2.2 缩进子功能块当在其父功能块后缩进。
当功能块过多而导致缩进过深时当将子功能块提取出来做为子函数。
代码中以TAB（4 个字符）缩进，在编辑器中请将TAB 设置为以空格替代，否则在不同编辑器或设置下会导致TAB 长度不等而影响整个程序代码的格式。
例如：Table1．缩进示例public void methodName(){if(some condition){for(…){//some sentences}//end for}//end if}2.3 长度为便于阅读和理解，单个函数的有效代码长度当尽量控制在80 行以内（不包括注释行），当一个功能模块过大时往往造成阅读困难，因此当使用子函数等将相应功能抽取出来，这也有利于提高代码的重用度。
单个类也不宜过大，当出现此类情况时当将相应功能的代码重构到其他类中，通过组合等方式来调用，建议单个类的长度包括注释行不超过1500 行。
尽量避免使用大类和长方法。
2.4 行宽页宽应该设置为80 字符。
一般不要超过这个宽度, 这会导致在某些机器中无法以一屏来完整显示, 但这一设置也可以灵活调整。
在任何情况下, 超长的语句应该在一个逗号后或一个操作符前折行。
一条语句折行后, 应该比原来的语句再缩进一个TAB 或 4 个空格，以便于阅读。
2.5 间隔类、方法及功能块间等应以空行相隔，以增加可读性，但不得有无规则的大片空行。
操作符两端应当各空一个字符以增加可读性。
相应独立的功能模块之间可使用注释行间隔，并标明相应内容，具体参看附录的代码示例第7 页/共7 页当方法参数过多时当在每个参数后（逗号后）换行并对齐。
当控制或循环中的条件比较长时当换行（操作符前）、对齐并注释各条件。
变量定义最好通过添加空格形成对齐，同一类型的变量应放在一起。
如下例所示：Table2．对齐示例2.7 括号{} 中的语句应该单独作为一行，左括号"{"当紧跟其语句后，右括号"}"永远单独作为一行且与其匹配行对齐，并尽量在其后说明其匹配的功能模块。
较长的方法以及类、接口等的右括号后应使用//end ...等标识其结束。
如:类的结束符：}//EOC ClassName，方法结束符：}//end methodName()，功能块结束：}//end erName is null?循环快结束：}//end for...every user in userList不要在程序中出现不必要的括号，但有时为了增加可读性和便于理解，当用括号限定相应项。
左括号是否换行等随个人习惯而定，若换行则当与其前导语句首字符对齐。
第3章注释3.1 基本原则3.1.1 3.1.23.1.3 3.1.4 3.1.5 3.1.6 3.1.7注释应该增加代码的清晰度。
代码注释的目的是要使代码更易于被其他开发人员等理解。
如果你的程序不值得注释，那么它很可能也不值得运行。
避免使用装饰性内容。
保持注释的简洁。
注释信息不仅要包括代码的功能，还应给出原因。
不要为注释而注释。
除变量定义等较短语句的注释可用行尾注释外，其他注释当避免使用行尾注释。
3.2 JavaDoc对类、方法、变量等的注释需要符合JavaDoc 规范，对每个类、方法都应详细说明其功能、条件、参数等，并使用良好的HTML 标记格式化注释，以使生成的JavaDoc 易阅读和理解。
3.3 文件与包注释在每个文件、包的头部都应该包含该文件的功能、作用、作者、版权以及创建、修改记录等。
并在其中使用CVS 标记自动跟踪版本变化及修改记录等信息。
注意是/**/注释而不是/***/JavaDoc 注释。
文件注释模板见附件《注释模板》中的文件注释部分。
版权声明部分请参见附件《版权声明》并注意更新到最新版本。
Table3 文件注释示例：每个包当有包注释，在源码及JavaDoc 相应包路径下建立package.html 以描述包的功能、作用等。
3.4 类、接口注释在类、接口定义之前当对其进行注释，包括类、接口的目的、作用、功能、继承于何种父类，实现的接口、实现的算法、使用方法、示例程序等，在作者和版本域中使用CVS 标记自动跟踪版本变化等，具体参看附件《注释模板》中相关部分。
3.5 方法注释依据标准JavaDoc 规范对方法进行注释，以明确该方法功能、作用、各参数含义以及返回值等。
复杂的算法用/**/在方法内注解出。
参数注释时当注明其取值范围等返回值当注释出失败、错误、异常时的返回情况。
异常当注释出什么情况、什么时候、什么条件下会引发什么样的异常3.6 其他注释应对重要的变量加以注释，以说明其含义等。
应对不易理解的分支条件表达式加注释。
不易理解的循环，应说明出口条件。
过长的方法实现，应将其语句按实现的功能分段加以概括性说明。
对于异常处理当注明正常情况及异常情况或者条件，并说明当异常发生时程序当如何处理。
3.7 注释参考表第4章命名4.1 基本原则规范的命名能使程序更易阅读，从而更易于理解。
它们也可以提供一些标识功能方面的信息，有助于更好的理解代码和应用。
4.1.1 4.1.2 4.1.3 4.1.44.1.5 4.1.6 4.1.7使用可以准确说明变量/字段/类/接口/包等的完整的英文描述符。
例如，采用类似firstName，listAllUsers 或CorporateCustomer 这样的名字，严禁使用汉语拼音及不相关单词命名，虽然Java 支持Unicode 命名，但本规范规定对包、类、接口、方法、变量、字段等不得使用汉字等进行命名。
采用该领域的术语。
如果用户称他们的“客户” (clients) 为“顾客”(customers)，那么就采用术语Customer 来命名这个类，而不用Client。
采用大小写混合，提高名字的可读性。
一般应该采用小写字母，但是类和接口的名字的首字母，以及任何中间单词的首字母应该大写。
包名全部小写。
尽量少用缩写，但如果一定要使用，当使用公共缩写和习惯缩写等，如实现（implement）可缩写成impl，经理（manager）可缩写成mgr 等，具体参看附录之《常用缩写简表》，严禁滥用缩写。
避免使用长名字（最好不超过25 个字母）。
避免使用相似或者仅在大小写上有区别的名字。
避免使用数字，但可用 2 代替to，用 4 代替for 等，如：go2Jsp。
4.2 文件、包4.2.1 4.2.2 4.2.3 4.2.44.2.5文件名当与其类严格相同，所有单词首字母大写。
包名一般以项目或模块名命名，少用缩写和长名，一律小写。
基本包：org.skyinn，所有包、文件都从属于此包。
包名按如下规则组成：[基本包].[项目名].[模块名].[子模块名]...如：org.skyinn.quasarorg.skyinn.skyhome.dao.hibernate不得将类直接定义在基本包下，所有项目中的类、接口等都当定义在各自的项目和模块包中。
4.3 类、接口所有单词首字母大写。
使用能确切反应该类、接口含义、功能等的词。
一般采用名词。
接口可带I 前缀或able、ible、er 等后缀。
4.4 字段4.4.1 常量采用完整的英文大写单词，在词与词之间用下划线连接，如：DEFAULT_VALUE4.4.2 变量和参数对不易清楚识别出该变量类型的变量应使用类型缩写作其前缀，如字符串使用strXXX,boolean 使用isXXX，hasXXX 等等。
除第一各个单词外其余单词首字母大写。
对私有实例变量可使用_前缀，但在其存取方法中则应该将其前缀去掉。
4.4.3 组件/部件应采用完整的英文描述符命名组件（接口部件），遵循匈牙利命名法则如：btnOK，lblName。
