以下可能是大多数专业JavaE序员都赞同、也愿意执行的八点规则：
1) 保持cL?/p>
q有什么比拥有较少的类更坏的事情吗Q可能不会再有了。当Ӟ最好还是有满自己需要的cR?/p>
一般来_一个带有大量方法的cLLh一些不属于q里的方法，因ؓq个庞大的对象所做的事情太多了。如果?zhn)有一个带?100 个方法的对象Q就应该好好xQ这个对象是否应该拆成多个对象。大c通常在大学里大行光。Java 代码与之一栗?/p>
2) 保持Ҏ(gu)最?/p>
方法就与小cM样可取，q且原因也类伹{?br>很多有经验的 OO E序员对 Java 语言h的苦g一是Q它提供大量?OO 能力Q但是却没有教他们如何做?OO。换句话_它给了他们很多子去捆绑自己Q尽至没?C++ l他们的多）。能看到q一点的一个常见地Ҏ(gu)
main()Ҏ(gu)d很远的类Q或者一个单个的名叫doIt()的方法。仅仅因?em>能够 所有的代码攑֜cM的单个方法中Qƈ不意味着?em>应该 如此。Java 语言比很多其?OO 语言h更多的语法糖Q所以一定的|嗦是必要的Q但是不要过了度?/p>思考一下这些超长的Ҏ(gu)。滚动十屏代码去了解代码所做的工作是很艰难的。该Ҏ(gu)做什么工作？(zhn)需要上一杯大大的咖啡花几个小时去研究才能知道。一个小的，甚至微小的方法是一个容易看懂的代码块。运行时效率不是要具有小Ҏ(gu)的原因，可读性才是真正的目标。这得代码更加容易维护，q且在需要添加功能时更加Ҏ(gu)更改?/p>
每个方法局限于执行一工作?/p>
3) l方法取好名U?/p>
本要求很单，只需要花上一Ҏ(gu)间想Z个具有描q性的Ҏ(gu)名，_明了但不q长?br>q一技巧很单，也许在小规模的代码行中是微不道的，但是当代码变得越来越复杂Ӟ它就会显露出惊h的威力?/p>
4) 保持cȝ数量最?/p>
XP 中关于简单设计的其中一个指导方针是Q用可能少的类完成一个目标。如果?zhn)需要另一个类Q尽添加就是了。如果另一个类得代码更单或者简化?zhn)的意图表达，那么添加这个类吧。但是没有理由只是ؓ了具有而具有类。当Ӟ通常目早期比结束时h的类要少Q但是一般将代码重构成更多的cLl合cLҎ(gu)。如果?zhn)有一个具有大量方法的c，那么分析一下，看是否有另一个对象陷入在其中Q正在等待出厅R如果有的话Q就创徏一个新的对象?/p>
在我l历的几乎所?Java 目上，没有人害怕创建类Q但是我们也L试图在不降低意图清晰度的情况下，减少cȝ数量?/p>
5) 保持注释的数据最?/p>
我过d常在代码中编写很多的注释Q读h像一本书。后来我变得聪明一些了?/p>
每一个计机U学E序、每一本编E书c和我知道的很多E序员，都要(zhn)给代码~写注释。在有些情况下，注释是有帮助的。在许多情况下，注释使得代码l护更加困难。想x更改代码时必d什么。有注释吗？如果有的话，(zhn)最好更Ҏ(gu)释，否则它会可怕地q期Q甚至随着旉的推U，Ҏ(gu)׃再能够描qC码。依我的l验Q几乎会使维护时间加倍?/p>
我的l验法则是：如果代码太难阅读和理解而需要注释，我就需要它够清晎ͼ从而不需要注释。代码可能会太长Q或者做太多的事情。如果这L(fng)话，我就化它。代码可能太隐晦。如果这L(fng)话，我就d助手Ҏ(gu)Q之清晰。实际上Q在与同一团队的其他成员一赯?Java ~程的三q当中，我所~写的注释屈指可数。保持代码清晎ͼ如果(zhn)需要系l或者某个特定组件的全景描述Q就~写一个简短的注释来描q?/p>
|嗦的注释一般比较难l护Q通常不及一个小的、编写良好的Ҏ(gu)那么好地表达意图Qƈ且很快就会过期。根本不要过分依赖注释?/p>
6) 使用一致的风格
~码风格实际上是(zhn)的环境中必然的q且可接受的东西。我甚至不知道哪一U风格可以称?#8220;典型?#8221;。这通常是个人品味问题?/p>
有时候，对于同一D代码，可能有好几种排列Ҏ(gu)Q实际上没有l对?#8220;?#8221;?#8220;?#8221;。实际项目过E中Q应该进行协商，挑选出一U来Q然后一直坚持用q一U。惟一l对的风D则是一致?/em>。如果一个项目上的每个h都用不同的风|那么阅读代码变得很困难。挑选一U风格ƈ且不要改变?/p>
7) 避免switch
一?Java E序员对
switch语句情有独钟。我曄认ؓ它们很好Q但是后来我认识CQ一?switch实际上就是几?ifQƈ且通常意味着条g逻辑出现在代码中的多个地斏V这是代码重复，是应该禁忌的。ؓ什么？因ؓ在多处具有相同的代码使得代码比较难更攏V如果我在三处具有相同的switchQƈ且想要更改对某个 case 的处理，我就得在三处更改代码?/p>现在Q如果?zhn)可以重构h单个
switch语句的代码，那会怎么样呢Q很好！我不怿使用它有什么坏处。在有些情况下，它比嵌套?if更清晰。但是如果?zhn)看到它出现在很多地方Q就有了应该解决的问题了。防止这一问题的一个容易的Ҏ(gu)是，避免switchQ除非它对于该工作是最佳的工具。依我的l验Q它很少是最佳的?/p>
8) 是public?/p>
我把最具争议的攑֜最后。做一下深呼吸?/p>
我相信?zhn)会反对让所有的Ҏ(gu)都是
public的。实例变量应该是protected的?/p>当然Q许多专业程序员会害怕这U想法，因ؓ如果M东西都是公共的，那么M人都可以更改它，也许会以未授权的方式更改。在M东西都是公共可访问的世界中，(zhn)就不得不依赖于E序员纪律，以确保h们在其不应该讉K时不会访问其不应该访问的东西。但是在~程生活当中Q很有什么事情比惌讉K一个不可见的变量或Ҏ(gu)更受挫的了。如果?zhn)对代码中?zhn)设惛_他h不应该访问的东西限制讉KQ?zhn)是在设惌己无所不知。这在大多数时候是一个危险的假设?/p>
当用其他h的代码时Q这U受挫感会经常出现。?zhn)会看C个方法刚好做(zhn)想要做的工作，但是它不是公共可讉K的。有Ӟq有一个很好的原因Qƈ且得限制可讉K性有意义。但是有Ӟ?
public的惟一原因是，~写代码的hq样?#8220;没有人需要访问该代码”Q或者他们这h“没有人应该访问该代码Q因?#8230;…”Q于是他们ƈ没有很好的理由。许多时候，Z使用private是因为它可用。不要这样做?/p>使方法是
public的，变量?protected的，直到(zhn)有一个很好的理由限制讉K?/p>
现在(zhn)知道了如何创徏优良?Java 代码Q以及如何保持它优良?/p>
关于该主题，业界最好的书籍?Martin Fowler ~著?RefactoringQ参?参考资?/font> 中的链接Q。它读v来甚臛_有趣?em>重构QrefactoringQ?/em> 的意思是在不改变代码l果的情况下Q更改现有代码的设计。Fowler 谈论了请求重构的“代码气味”Qƈ且详l介l了用于改变“代码气味”的各U技巧（或?#8220;重构”Q。依我的观点Q重构和~写一ơ通过试的代码的能力Q参?参考资?/font>Q是新手E序员要学习的最重要的技能。如果每个h都擅长于q两点，那将d改变行业当前的局面。如?em>(zhn)?/em> 擅长于这两点Q就会比较容易找到工作，因ؓ(zhn)能比其他h产生更好的结果?/p>
~写 Java 代码相当单。编?em>优良?/em> Java 代码则是一门手艺。們֊成ؓ一个手Zh?/p>