JAVA优质代码编写的30条可行建议

编辑：bwin必赢官网时间：2024-05-13 点击：

本文摘要：JAVA优质代码撰写的30条不切实际建议列出了大量简单的建议，协助大家展开低级程序设计，并获取了代码撰写的一般性指导：(1)类名首字母应当大写。字段、方法以及对象（句柄）的首字母不应小写。对于所有标识符，其中包括的所有单词都不应紧靠在一起，而且大写中间单词的首字母。例如：ThisIsAClassNamethisIsMethodOrFieldName1/13若在定义中经常出现了常数初始化字符，则大写staticfinal基本类型标识符中的所有字母。

bwin必赢官网

JAVA优质代码撰写的30条不切实际建议列出了大量简单的建议，协助大家展开低级程序设计，并获取了代码撰写的一般性指导：(1)类名首字母应当大写。字段、方法以及对象（句柄）的首字母不应小写。对于所有标识符，其中包括的所有单词都不应紧靠在一起，而且大写中间单词的首字母。例如：ThisIsAClassNamethisIsMethodOrFieldName1/13若在定义中经常出现了常数初始化字符，则大写staticfinal基本类型标识符中的所有字母。

这样之后可标志出有它们归属于编译器期的常数。Java包在（Package）归属于一种类似情况：它们全都是小写字母，即便中间的单词亦是如此。对于域名拓展名称，如com，org，net或者edu等，全部都不应小写（这也是Java1.1和Java1.2的区别之一）。2/13(2)为了常规用途而创立一个类时，请求采行“经典形式”，并包括对特例元素的定义：equals()hashCode()toString()clone()（implementCloneable）implementSerializable3/13(3)对于自己创立的每一个类，都考虑到重复使用一个main()，其中包括了用作测试那个类的代码。

为用于一个项目中的类，我们没有适当移除测试代码。若展开了任何形式的改动，可便利地回到测试。这些代码也可作为如何用于类的一个示例用于。(4)不应将方法设计成详细的、功能性单元，用它叙述和构建一个不倒数的类模块部分。

理想情况下，方法不应简明扼要。若长度相当大，可考虑到通过某种方式将其拆分成较短的几个方法。这样做到也便于类内代码的重复使用（有些时候，方法必需十分大，但它们仍不应只做到某种程度的一件事情）。

4/13(5)设计一个类时，请求设身处地为客户程序员考虑一下（类的用于方法应当是十分具体的）。然后，再行设身处地为管理代码的人考虑一下（预计有可能展开哪些形式的改动，看看用什么方法可把它们显得更加非常简单）。(6)使类尽量短小精悍，而且只解决问题一个特定的问题。

下面是对类设计的一些建议：■一个简单的电源语句：考虑到使用“多形”机制■数量众多的方法牵涉到到类型差异很大的操作者：考虑到用几个类来分别构建■许多成员变量在特征上有相当大的差异：考虑到用于几个类5/13(7)让一切东西都尽量地“私有”——private。可使库的某一部分“公共化”（一个方法、类或者一个字段等等），就总有一天无法把它拿走。若擅自拿走，就有可能毁坏其他人现有的代码，使他们被迫新的撰写和设计。

若只发布自己必需发布的，就可放心大胆地转变其他任何东西。在多线程环境中，隐私是尤其最重要的一个因素——只有private字段才能在非实时用于的情况下受到维护。(8)谨惕“极大对象综合症”。

对一些习惯于顺序编程思维、且初涉OOP领域的新手，往往讨厌再行写出一个顺序继续执行的程序，再行把它映射一个或两个极大的对象里。根据编程原理，对象传达的应当是应用程序的概念，而非应用程序本身。(9)若只好展开一些不过于雅观的编程，最少应当把那些代码置放一个类的内部。6/13(10)任何时候只要找到类与类之间融合得十分密切，就必须考虑到否使用内部类，从而提高编码及确保工作（参看第14章14.1.2小节的“用内部类改良代码”）。

(11)尽量精细地再加注解，后用javadoc注解文档语法分解自己的程序文档。(12)防止用于“魔术数字”，这些数字很难与代码很好地因应。

如以后必须改动它，毫无疑问不会沦为一场噩梦，因为显然不告诉“100”究竟是指“数组大小”还是“其他全然不同的东西”。所以，我们不应创立一个常数，并为其用于具备说服力的描述性名称，并在整个程序中都使用常数标识符。

这样可使程序更加不易解读以及更加不易确保。7/13(13)牵涉到建构器和出现异常的时候，一般来说期望新的弃置在建构器中捕捉的任何出现异常——如果它造成了那个对象的创立告终。

这样一来，调用者就会以为那个对象已正确地创立，从而盲目地之后。(14)当客户程序员用完了对象以后，若你的类拒绝展开任何清理工作，可考虑到将清理代码置放一个较好定义的方法里，使用类似于cleanup()这样的名字，具体指出自己的用途。

除此以外，可在类内摆放一个boolean（布尔）标记，认为对象否已被清理。在类的finalize()方法里，请求确认对象已被清理，并已弃置了从RuntimeException承继的一个类（如果还没的话），从而认为一个编程错误。

在采行象这样的方案之前，请求确认finalize()需要在自己的系统中工作（有可能必须调用System.runFinalizersOnExit(true)，从而保证这一不道德）。8/13(15)在一个特定的起到域内，若一个对象必需清理（非由垃圾搜集机制处置），请求使用特例方法：初始化对象；若顺利，则立刻转入一个所含finally子句的try块，开始清理工作。(16)若在初始化过程中必须覆盖面积（中止）finalize()，请求忘记调用super.finalize()（若Object归属于我们的必要超类，则无此适当）。

在对finalize()展开覆盖面积的过程中，对super.finalize()的调用不应归属于最后一个行动，而不不应是第一个行动，这样可保证在必须基础类组件的时候它们仍然有效地。(17)创立大小相同的对象子集时，请求将它们传输至一个数组（若打算从一个方法里回到这个子集，更加不应如此操作者）。这样一来，我们就可享用到数组在编译器期展开类型检查的益处。

此外，为用于它们，数组的接收者或许并不需要将对象“造型”到数组里。9/13(18)尽可能用于interfaces，不要用于abstract类。若未知某样东西打算沦为一个基础类，那么第一个自由选择不应是将其变为一个interface（模块）。只有在被迫用于方法定义或者成员变量的时候，才必须将其变为一个abstract（抽象化）类。

模块主要叙述了客户期望做到什么事情，而一个类则致力于（或容许）明确的实行细节。(19)在建构器内部，只展开那些将对象另设为准确状态所需的工作。尽量地防止调用其他方法，因为那些方法有可能被其他人覆盖面积或中止，从而在建构过程中产生不能预见的结果（参看第7章的详尽解释）。(20)对象不不应只是非常简单地容纳一些数据；它们的不道德也不应获得较好的定义。

10/13(21)在现成类的基础上创立新的类时，请求首先自由选择“新建”或“创作”。只有自己的设计拒绝必需承继时，才不应考虑到这方面的问题。

若在本来容许新建的场合用于了承继，则整个设计不会显得没适当地简单。(22)用承继及方法覆盖面积来回应不道德间的差异，而用字段回应状态间的区别。

一个十分极端的例子是通过对有所不同类的承继来回应颜色，这是意味著应当防止的：不应必要用于一个“颜色”字段。(23)为防止编程时遇上困难，请求确保在自己类路径指到的任何地方，每个名字都仅有对应一个类。

否则，编译器有可能再行寻找同名的另一个类，并报告错误消息。若猜测自己遇到了类路径问题，请求试试在类路径的每一个起点，搜寻一下同名的.class文件。11/13(24)在Java1.1AWT中用于事件“适配器”时，尤其更容易遇到一个陷阱。

若覆盖面积了某个适配器方法，同时拼法方法没尤其讲究，最后的结果就是新的加到一个方法，而不是覆盖面积现成方法。然而，由于这样做到是几乎合法的，所以会从编译器或运营期系统取得任何错误提醒——只不过代码的工作就显得不长时间了。

(25)用合理的设计方案避免“伪功能”。也就是说，假若只必须创立类的一个对象，就不要提早容许自己用于应用程序，并再加一条“只分解其中一个”注解。请求考虑到将其PCB成一个“独生子”的形式。若在主程序里有大量杂乱的代码，用作创立自己的对象，请求考虑到接纳一种创造性的方案，将些代码PCB一起。

(26)警觉“分析中断”。请求忘记，无论如何都要提早理解整个项目的状况，再行去实地考察其中的细节。

由于做到了全局，可较慢了解自己不得而知的一些因素，避免在实地考察细节的时候陷于“杀逻辑”中。12/13(27)警觉“过早优化”。首先让它运营一起，再考虑显得更加慢——但只有在自己必需这样做到、而且经证实在某部分代码中的确不存在一个性能瓶颈的时候，才不应展开优化。

除非用专门的工具分析瓶颈，否则很有可能是在浪费自己的时间。性能提高的说明了代价是自己的代码显得难以解读，而且难以确保。(28)请求忘记，读者代码的时间比写出代码的时间非常少。思路清晰的设计可取得更容易解读的程序，但注解、精细的说明以及一些示例往往具备不可估量的价值。

无论对你自己，还是对后来的人，它们都是非常最重要的。如回应仍有猜测，那么请求比如说自己企图从联机Java文档里找到简单信息时遇到的挫折，这样也许能将你劝说。(29)如指出自己已展开了较好的分析、设计或者实行，那么请求略为替换一下思维角度。

试试邀一些外来人士——不一定是专家，但可以是来自本公司其他部门的人。请求他们用几乎新鲜的眼光实地考察你的工作，想到否能找到你一度熟视无睹的问题。

采行这种方式，往往能在最合适改动的阶段找到一些关键性的问题，防止产品发售后再行解决问题而导致的金钱及精力方面的损失。13/13(30)较好的设计能带给仅次于的报酬。