java编程风格-the elements of java style-高清晰pdf版

【文件属性】：
文件名称：java编程风格-the elements of java style-高清晰pdf版
文件大小：227KB
文件格式：PDF
更新时间：2012-06-15 09:15:29
java java编程风格 编程风格 编程规范 一本薄薄的《Java编程风格(英汉对照)》，却有7位作者，Amazon上得33位读者如潮好评——这是一本怎样的奇书？ 《Java编程风格(英汉对照)》是一部久经考验、短小精悍的Java编规范，结合了世界领先的企业级组件和基础架构软件开发商Rogue Wave公司和著名软件工程专家Scott W．Ambler多年经验的结晶。书中的108条Java编码规则和建议涵盖了格式、命名、文档、程序、包，以及泛型、线程全等较高级的内容，既能够帮助广大程序员加深对Java语言的理解，编写出更易于理解、更高质量的Java代码。更是打造优秀Java开发团队的利器。 龚刚提供 欢迎访问我的博客:http://javafun.yo2.cn javafun,java is fun 认真做软件 仔细听潮流 大胆跟时代 小心写文章 总则(来源与互联网) 1。坚持原有代码的规范 当修改现有代码时，修改应该仍然遵守原来代码的规范。不要试图只修改代码规范来重写原有代码，否则很容易产生错误。 参见：http://www.gui.com.au/jkoding.htm 2。坚持最少astonishment原则 应该避免程序产生让用户感到奇怪的行为。应该遵循下面的准则： 简单：写简单的类和简单的方法。决定做到何种程度就可以满足用户的需求。 明确：保证每个类、接口、方法、变量和对象都有明确的目的。 完整：创建完整的文档；对所有的特征和工作做文档。 一致：风格要一致。相似的东西应该看起来相似，行为相似。尽量创建和应用标准。 鲁棒性：提供对错误和异常的可预见的处理。 3。立即应用这些规则。 把这些规则应用到你要写的任何代码中。包括原型开发的代码，等等。 4。对任何偏离规范的变化做文档。 没有标准是完美的。有时候不得不打破它。首先要理解你要打破的规则的存在理由和后果，其次要为所作的变化做文档。 格式规范 5。缩进被括起来的代码。 //关于匿名内置类 6。打破长句子 7。使用空格和空行。 8。不要用tab键。 命名规范 9-14. 用有语义的、大家熟悉的名字。 对过长的名字质疑。 尽量保留名字中的元音字母。对于像XML这样全部大写的缩写，在名字中不必全大写。不要只通过大小写使得两个名字不同。 15-17. 包命名格式：小写；以域名开头。用有意义的名字。不同版本要用新的包名。 //这样的话新版本包的命名是个麻烦事。 18-21。类和接口命名。 22-24. 方法命名。 25－31。 变量和常量命名。 注释规范 32。为那些阅读和维护你代码的人写文档。 那个人很可能就是你自己。 33。注释和代码同步。 34。用准确的语言。 35－37。三种注释的用法。 38。在写代码前写注释。 39. 为所有的成员写文档注释。 40。为包写注释。 41。为一个应用或者一组包写注释。注释内容也是写在一个html文件的中，也可以使用除@link之外的任何标记。生成文档时用-overview指明这个html文件。 42. 用一种统一的格式做文档注释。 43-45。把关键字、identifiers/constants放在中。把源码放在

中。把首次出现的identifier用{@link} 标记，这个标记的作用是生成一个超级链接。例如{@link #Flag(boolean)}是指向本类的一个方法。 46。类、方法、成员变量的文档注释格式。 47。叙述一个类的功能时，尽量不用主语，而谓语采用第三人称单数。常用的动词有： adds, deallocates(释放分配的资源）, removes, allocates, destroys, returns, computes, gets, sets, constructs, provides, tests converts, reads, writes，alpplies 48. 写简述。简述放在第一句。 49。一个动作、服务的简述不要写主语。 50。一个东西的简述不要写主语和谓语。 51。指代当前类是用this而不用the。 52。除非特指一个特定的方法，在提到方法名不要带括号。 意思是说，存在overloaded的方法，如果要泛指同名的方法，就不要带括号，如果特指某一方法，则需要加上括号并列出参数类型。 53。为每个类、接口、成员变量、方法写注释. 54. 为方法做完整的描述。 55。包含例子。在必要时。 56。为方法的前提（例如参数值的限制）、结果（例如类的状态改变）、限制（例如一个叫做vavationDays的变量限制在0－30之间）。 57。为错误和缺陷做注释。 58。为同步语义做注释。 59。只在对别人有帮助时加入内部注释（大概是指方法内部的注释）。 60。描述代码为什么这样做，而不是做什么。代码本身能说明自己在做什么。//这一点保留意见。为什么这样做应该在设计文档或者需求文档中说明了。 61。尽量避免把行末注释放在行末。因为修改这行代码时可能导致一行很长而把注释推到不容易看到的地方。 把行末注释放在要解释的代码之前，而且另起一行。 62。对变量的注释放在行末。 63。确定一组关键字来说明没有解决的事情。尤其用在代码还没有完成的时候。一般还包括一个时间.例如： //:UNRESOLEVED: EBW, 2005-7-20 这种注释我保留意见。因为关键字说不清楚。 64。对多层嵌套的控制结构，对每个右大括弧做注释。例如 //end if 之类的。如果采用每个大括弧单独成行而且相应括号对齐的话，这种注释就可以取消了。 65。在switch语句中，如果一个case之后没有break语句，则一定要加上一句注释://fall though! . 66。如果一个控制结构之后的语句块是空的，则请注明 //Empty!。例如 for (int i=0; i