 |
|
|
 首页 |
名片设计 CorelDRAW Illustrator AuotoCAD Painter 其他软件 Photoshop Fireworks Flash |
|
1. 应用范围 本规范应用于采用J2EE规范的项目中，所有项目中的JAVA代码（含JSP，SERVLET，JAVABEAN，EJB）均应遵守这个规范。同时，也可作为其它项目的参考。 2. 设计类和方式 2.1 创建具有很强内聚力的类 方式的重要性往往比类的重要性更轻易理解，方式是指执行一个统一函数的一段代码。类常被错误的视为是一个仅仅用于存放方式的容器。有些开发人员甚至把这种思路作了进一步的发挥，将他们的所有方式放入单个类之中。 之所以不能准确的熟悉类的功能，原因之一是类的实现实际上并不影响程序的执行。当一个工程被编译时，假如所有方式都放在单个类中或者放在几十个类中，这没有任何关系。虽然类的数量对代码的执行并无太大的影响，但是当创建便于调试和维护的代码时，类的数量有时会带来很大的影响。 类应该用来将相关的方式组织在一起。 当类包含一组紧密关联的方式时，该类可以说具有强盛的内聚力。当类包含许多互不相关的方式时，该类便具有较弱的内聚力。应该努力创建内聚力比较强的类。 大多数工程都包含许多并不十分适合与其他方式组合在一起的方式。在这种情况下，可以为这些不合群的方式创建一个综合性收容类。 创建类时，应知道“模块化”这个术语的含义是什么。类的基本目的是创建相称独立的程序单元。 2.2 创建松散连接和高度专用的方式 1. 使所有方式都执行专门的任务 每个方式都应执行一项特定的任务，它应精彩的完成这项任务。应避免创建执行许多不同任务的方式。 创建专用方式有许多好处。首先调试将变得更加轻易。 2. 尽量使方式成为自成一体的独立方式 当一个方式依靠于其他方式的调用时，称为与其他方式紧密连接的方式。紧密连接的方式会使调试和修改变得比较困难，因为它牵涉到更多的因素。松散连接的方式优于紧密连接的方式，但你不可能使每个方式都成为独立的方式。 若要使方式具备较强的独立性，方式之一是尽量减少类变量。 创建方式时，设法将每个方式视为一个黑箱，其他例程不应要求了解该方式的内部工作情况，该方式也不应要求了解它外面的工程情况。这就是为什么你的方式应依赖参数而不应依赖全局变量的原因。 创建专用方式时，请考虑下列指导原则： 1) 将复杂进程放入专用方式。假如应用程序使用复杂的数学公式，请考虑将每个公式放入它自己的方式中。这样使用这些公式的其他方式就不包含用于该公式的实际代码。这样也可以更轻易发现与公式相关的问题。 2) 将数据输入/输出（I/O）放入专用方式。 3) 将专用方式中可能要修改的代码隔离。假如你知道某个进程常常变更，请将这个多变的代码放入专用方式，以便以后可以更轻易的进行修改，并减少无意中给其他进程带来问题的可能性。 4) 将业务规则封装在专用方式中。业务规则常属于要修改的代码类别，应与应用程序的其余部分隔开。其他方式不应知道业务规则，只有要调用的方式才使用这些规则。 3. 设计类和方式时，要达到下列目的： 1) 创建更加轻易调试和维护的方式 2) 创建具有强盛内聚力的类 3) 创建高度专用的方式 4) 创建松散连接的方式 5) 尽量使方式具有独立性 6) 提高方式的扇入性 7) 降低方式的扇出性 2.3 编程原则 1. 为方式和类赋予表义性强的名字 为了使代码更加轻易理解，最轻易的方式之一是为你的方式赋予表义性强的名字。函数名DoIt、GetIt的可读性很难与CalculateSalesTax、 RetrieveUserID相比。 由缩写方式名组成的代码很难理解和维护，没有理由再这样做了。 给方式准确的命名，可使程序工程的调试和维护工作大大的改观。请认真对待方式命名的工作，不要为了减少键入操作量而降低方式的可理解度。 实际应用举例： 1) 给方式命名时应大小写字母混合使用。假如句子全使用大写字母，那么阅读起来就异常困难，而大小写字母混合使用的句子，阅读起来就很轻易。 2) 定义方式名时不要使用缩写。假如你认为应用程序中的某些工程应使用缩写，那么请将这些情况加上注释，并确保每个人在所有时间内都使用这些缩写。决不要在某些方式中对某些单词进行缩写，而在别的方式中却不使用缩写。 2. 为每个方式赋予单个退出点 3. 创建方式时，始终都应显式地定义它的作用域。 1) 假如你真的想创建一个公用方式，请向代码阅读者说明这一点。 2) 通过为每个方式赋予一个明确定义的作用域，可以减少代码阅读者需要投入的工作量。应确保你为方式赋予最有意义的作用域。假如一个方式只被同一类中的另一个方式调用，那么请将它创建成私有方式。假如该方式是从多个类中的多个方式中调用，请将该说明为公用方式。 4. 用参数在方式之间传递数据 应尽量避免使用类变量。一般来说，变量的作用域越小越好。为了减少类变量，方式之一是将数据作为参数在不同方式之间传递，而不是让方式共享类变量。 1) 为每个参数指定数据类型。 2) 始终要对数进行检验，决不要假设你得数据没有问题。程序员常犯的一个错误是在编写方式时假设数据没有问题。在初始编程阶段，当编写调用方式时，这样的假设并无大碍。这时你完全能够知道什么是参数的许可值，并按要求提供这些值。但假如你不对参数的数据进行检验，那么下列情况就会给你带来很大麻烦：另外某个人创建了一个调用方式，但此人不知道答应的值；你在晚些时候添加了新的调用方式，并错误的传递了坏数据。 3. 命名约定 所有变量的定义应该遵循匈牙利命名法，它使用3字符前缀来表示数据类型，3个字符的前缀必须小写，前缀后面是由表意性强的一个单词或多个单词组成的名字，而且每个单词的首写字母大写，其它字母小写，这样保证了对变量名能够进行准确的断句。 这样，在一个变量名就可以反映出变量类型和变量所存储的值的意义两方面内容，这使得代码语句可读性强、更加轻易理解。 3.1 包、类及方式命名 标示符类型 命名约定 例子 包 l 全部小写。 l 标识符用点号分隔开来。为了使包的名字更易读，Sun 公司建议包名中的标识符用点号来分隔。 l Sun 公司的标准 java 分配包用标识符 .java 开头。 l 全局包的名字用你的机构的 Internet 保留域名开头 。 局部包： interface.screens 全局包： com.rational.www. interface.screens 类，接口 l 类的名字应该使用名词。 l 每个单词第一个字母应该大写。 l 避免使用单词的缩写，除非它的缩写已经广为人知，如HTTP。 Class Hello ; Class HelloWorld ; Interface Apple ; 方式 l 第一个单词一般是动词。 l 第一个字母是小些，但是中间单词的第一个字母是大写。 l 假如方式返回一个成员变量的值，方式名一般为get+成员变量名，如若返回的值是bool变量，一般以is作为前缀。 l 假如方式修改一个成员变量的值，方式名一般为：set + 成员变量名。 getName(); setName(); isFirst(); 变量 l 第一个字母小写，中间单词的第一个字母大写。 l 不要用_或&作为第一个字母。 l 尽量使用短而且具有意义的单词。 l 单字符的变量名一般只用于生命期异常短暂的变量。i,j,k,m,n一般用于integers；c,d,e一般用于characters。 l 假如变量是集合，则变量名应用复数。 l 命名组件采用匈牙利命名法，所有前缀均应遵循同一个组件名称缩写列表。 String myName; int[] students; int i; int n; char c; btNew; (bt是Button的缩写) 常量 l 所有常量名均全部大写，单词间以‘_’隔开。 int MAX_NUM; 3.2 其它 开发人员假如碰到上述表格中未列举的类型，请书面通知相关治理人员，由治理人员集中更新列表内容，不得擅自启用未经确定的新变量前缀。 4. 使用常量 4.1 使用常量 1. 常数很轻易在数据输入时出错 常数存在的主要问题之一是你很轻易在键入数字时出错，从而颠倒了数字的位置。例如，当你键入数字10876时，很轻易的键入10867或18076。与处理变量和保留字的方式不同，编译器并不在乎颠倒了位置和不准确的数字，有时简朴的错误造成的问题不会立刻表现出来，而当问题表现出来时，它们会以随机的计算错误的形式出现，这些错误很难正确定位。用常量来取代常数时，编译器将在编译时检查常量的有效性。假如常量不存在，编译器便将这一情况通知你，并拒绝进行编译，这可以消除错误键入的数字带来的问题，只要常量拥有准确的值，使用该常量的所有代码也有使用该准确值。 2. 常数很难不断更新 3. 常量使代码更轻易阅读 使用常量后，得到的一个额外好处是可使创建的代码更轻易阅读。常数很不直观。也许你对常数异常了解，但其他人则根本看不明白。通过合理的给常量命名，使用这些常量的代码就变得比较直观了，更轻易阅读。 为常量赋予较宽的作用域，这与使用变量时的情况不同。在一个应用程序中你决不应该两次创建一样的常量。假如你发现自己复制了一个常量，请将原始的常量说明转至较宽的作用域，直到该常量可供引用它的所有方式为止。 5. 变量 5.1 定义有焦点的变量 用于多个目的的变量称为无焦点（多焦点）的变量。无焦点变量所代表的意义与程序的执行流程有关，当程序处于不同位置时，它所表示的意义是不固定的，这样就给程序的可读性和可维护性带来了麻烦。 5.2 只对常用变量名和长变量名进行缩写 假如需要对变量名进行缩写时，一定要注重整个代码中缩写规则的一致性。例如，假如在代码的某些区域中使用Cnt，而在另一些区域中又使用Count，就会给代码增加不必要的复杂性。 变量名中尽量不要出现缩写。 5.3 使用统一的量词 通过在结尾处放置一个量词，就可创建更加统一的变量，它们更轻易理解，也更轻易搜索。例如，请使用strCustomerFirst和strCustomerLast，而不要使用strFirstCustomer和strLastCustomer。 量词列表： 量词后缀 说明 First 一组变量中的第一个 Last 一组变量中的最后一个 Next 一组变量中的下一个变量 Prev 一组变量中的上一个 Cur 一组变量中的当前变量 5.4 使用肯定形式的布尔变量 给布尔变量命名时，始终都要使用变量的肯定形式，以减少其它开发人员在理解布尔变量所代表的意义时的难度。 5.5 为每个变量选择最佳的数据类型 这样即能减少对内存的需求量，加快代码的执行速度，又会降低出错的可能性。用于变量的数据类型可能会影响该变量进行计算所产生的结果。在这种情况下，编译器不会产生运行期错误，它只是迫使该值符合数据类型的要求。这类问题极难查找。 5.6 尽量缩小变量的作用域 假如变量的作用域大于它应有的范围，变量可继承存在，并且在不再需要该变量后的很长时间内仍旧占用资源。 它们的主要问题是，任何类中的任何方式都能对它们进行修改，并且很难跟踪毕竟是何处进行修改的。 占用资源是作用域涉及的一个重要问题。对变量来说，尽量缩小作用域将会对应用程序的可靠性产生巨大的影响。 6. 代码的格式化 6.1 对代码进行格式化时，要达到的目的 1. 通过代码分割成功能块和便于理解的代码段，使代码更轻易阅读和理解； 2. 使用空行和注释行，将程序中逻辑上不相关的代码块分开。比如：变量声明部分和代码语句间的分隔；较长的方式中，完成不同功能的代码块间的分隔。要避免出现逻辑上混乱的分隔，如：某一逻辑功能代码块中间用空行进行了分隔，但是在相邻功能代码块之间却没有分隔，这样会给程序阅读者造成错觉。 3. 减少为理解代码结构而需要做的工作； 4. 使代码的阅读者不必进行假设； 5. 使代码结构尽可能做到格式清晰明了。 6.2 编程原则 1. 要将多个语句放在同一行上 不论是变量声明，还是语句都不要在一行上书写多个。 2. 缩进后续行 当你将变量设置为某个值时，所有后续行的缩进位置应与第一行的变量值一样； 当你调用一个方式时，后续行缩进到第一个参数的开始处； 当你将变量或属性设置为等于表达式的计算结果时，请从后面分割该语句，以确保该表达式尽可能放在同一行上。 3. 在if语句后缩进； 在else语句后缩进 在switch语句后缩进 在case语句后缩进 在do句后缩进 已经用行接续符分割的语句的各个行要缩进 对从属于行标注的代码进行缩进。 4. 在执行统一任务的各个语句组之间插入一个空行。好的代码应由按逻辑顺序排列的进程或相关语句组构成。 7. 代码的注释 7.1 使用代码注释的目的 1. 文字说明代码的作用(即为什么要用编写该代码,而不是如何编写); 2. 确指出该代码的编写思路和逻辑方式; 3. 人们注重到代码中的重要转折点; 4. 使代码的阅读者不必在他们的头脑中仿真运行代码的执行方式. 7.2 编程原则 1. 用文字说明代码的作用: 简朴的重复代码做写什么,这样的注释几乎不能给注释增加什么信息.假如你使用好的命名方式来创建直观明了的代码那么这些类型的注释绝对增加不了什么信息. 2. 假如你想违反好的编程原则,请说明为什么 有的时候你可能需要违反好的编程原则，或者使用了某些不正规的方式，.碰到这种情况时,请用内部注释来说明你在做什么和为什么要这样做。 技巧性特殊高的代码段，一定要加具体的注释，不要让其他开发人员花很长时间来研究一个高技巧但不易理解的程序段。 3. 用注释来说明何时可能出错和为什么出错 4. 在编写代码前进行注释 给代码加注释的方式之一是在编写一个方式前首先写上注释.假如你愿意,可以编写完整句子的注释或伪代码.一旦你用注释对代码进行了概述,就可以在注释之间编写代码. 5. 在要注释的代码前书写注释 注释一定出现在要注释的程序段前，不要在某段程序后书写对这段程序的注释，先看到注释对程序的理解会有一定帮助。 假如有可能，请在注释行与上面代码间加一空行。 6. 纯色字符注释行只用于主要注释 注释中要分隔时，请使用一行空注释行来完成，不要使用纯色字符，以保持版面的整齐、清楚。 7. 避免形成注释框 用星号围成的注释框，右边的星号看起来很好,但它们给注释增加了任何信息吗?实际上这会给编写或编辑注释的人增加许多工作。 8. 增强注释的可读性 注释是供人阅读的，而不是让计算机阅读的。 1) 使用完整的语句。虽然不必将注释分成段落（最好也不要分成段落），但你应尽量将注释写成完整的句子。 2) 避免使用缩写。缩写常使注释更难阅读，人们常用不同的方式对一样的单词进行缩写，这会造成许多混乱，假如必须对词汇缩写，必须做到统一。 3) 将整个单词大写，以突出它们的重要性。若要使人们注重注释中的一个或多个单词，请全部使用大写字母。 9. 对注释进行缩进，使之与后随的语句对齐。 注释通常位于它们要说明的代码的前面。为了从视觉上突出注释与它的代码之间的关系，请将注释缩进，使之与代码处于同一个层次上。 10. 为每个方式赋予一个注释标头 每个方式都应有一个注释标头。方式的注释标头可包含多个文字项，比如输入参数、返回值、原始作者、最后编辑该方式的程序员、上次修改日期、版权信息。 11. 当行尾注释用在上面这种代码段结构中时，它们会使代码更难阅读。 使用多个行尾注释时（比如用于方式顶部的多个变量说明），应使它们互相对齐。这可使它们稍轻易阅读一些。 12. 何时书写注释 1) 请在每个if语句的前面加上注释。 2) 在每个switch语句的前面加上注释。与if语句相同，switch语句用于评估对程序执行产生影响的表达式。 3) 在每个循环的前面加上注释。每个循环都有它的作用，许多情况下这个作用不清晰直观。 7.3 注释那些部分 项目 注释哪些部分 实参/ 参数 参数类型 参数用来做什么 任何约束或前提条件 示例 字段/ 字段/属性 字段描述 注释所有使用的不变量 示例 并行事件 可见性决策 类 类的目的 已知的问题 类的开发/维护历史 注释出采用的不变量 并行策略 编译单元 每一个类/类内定义的接口，含简朴的说明 文件名和/或标识信息 版权信息 接口 目的 它应如何被使用以及如何不被使用 局部变量 用处/目的 成员函数注释 成员函数做什么以及它为什么做这个 哪些参数必须传递给一个成员函数 成员函数返回什么 已知的问题 任何由某个成员函数抛出的非常 可见性决策 成员函数是如何改变对象的 包含任何修改代码的历史 如何在适当情况下调用成员函数的例子适用的前提条件和后置条件 成员函数内部注释 控制结构 代码做了些什么以及为什么这样做 局部变量 难或复杂的代码 处理顺序 7.4 示例 7.4.1 块注释： 主要用来描述文件，类，方式，算法等。一般用在文档和方式的前面，也可以放在文档的任何地方。以‘/*’开头，‘*/’结尾。例： …… /* * 注释 */ …… 7.4.2 行注释： 主要用在方式内部，对代码，变量，流程等进行说明。与块注释格式相似，但是整个注释占据一行。例： …… /* 注释 */ …… 7.4.3 尾随注释： 与行注释功能相似，放在代码的同行，但是要与代码之间有足够的空间，便于分清。例： int m=4 ; /* 注释 */ 假如一个程序块内有多个尾随注释，每个注释的缩进应该保持一致。 7.4.4 行尾注释： 与行注释功能相似，放在每行的最后，或者占据一行。以‘//’开头。 7.4.5 文档注释： 与块注释相似，但是可以被javadoc处理，生成HTML文件。以‘/**’开头，‘*/’结尾。文档注释不能放在方式或程序块内。例： /** 注释 */ 8. 表达式和语句 8.1 每行应该只有一条语句。 8.2 if-else,if-elseif语句，任何情况下，都应该有“{”，“}”，格式如下： if (condition) { statements; } else if (condition) { statements; } else{ statements; } 8.3 for语句格式如下： for (initialization; condition; update) { statements; } 假如语句为空： for (initialization; condition; update) ; 8.4 while语句格式如下： while (condition) { statements; } 假如语句为空: while (condition); 8.5 do-while语句格式如下： do { statements; } while (condition); 8.6 switch语句，每个switch里都应包含default子语句,格式如下： switch (condition) { case ABC: statements; /* falls through */ case DEF: statements; break; case XYZ: statements; break; default: statements; break; } 8.7 try-catch语句格式如下： try { statements; } catch (ExceptionClass e) { statements; } finally { statements; } 9. 错误处理和非常事件 通常的思想是只对错误采用非常处理：逻辑和编程错误，设置错误，被破坏的数据，资源耗尽，等等。 通常的法则是系统在正常状态下以及无重载和硬件失效状态下，不应产生任何非常。非常处理时可以采用适当的日志机制来报告非常，包括非常发生的时刻。不要使用非常实现来控制程序流程结构。 10. 封装、事务 1. 非商务公用组件单独封装 2. 每一个业务流程单独封装 3. 一次方式（组件）的调用应能完成某一项功能或流程，即符合完整性 4. 一次方式（组件）的调用符合ACID事务性 5. 多次方式（组件）的调用应包含在一个事务中 11. 可移植性 1. 尽量不要使用已经被标为不赞成使用的类或方式。 2. 假如需要换行的话，尽量用 println 来代替在字符串中使用"/n"。 3. 用separator()方式代替路径中的”/”或”/” 。 4. 用pathSeptarator()方式代替路径中的 ” : ” 或 ” ;” 。 返回类别: 教程 上一教程: 面向对象WEB开发框架：ECHO2 卷土重来 下一教程: java学习笔记--Hiding implementation 您可以阅读与"JAVA 编程规范"相关的教程: · JAVA编程规则 · Java编程规则 · Java Socket编程（二） · JAVA进阶学习:网络服务器编程 · 在JAVA中编程实现数字签名系统 |
  |
| 快精灵印艺坊 版权所有 |
首页 会员中心在线印刷在线编辑付款方式索取样品设计指南连锁门店
|
||
