在IBM的developerworks網(wǎng)站上看java的基礎(chǔ)教程，將編寫修良java代碼的建議
1是保持類最小，如果你的類有100個(gè)方法，可能就要考慮考慮是不是要設(shè)計(jì)成幾個(gè)對(duì)象。呵呵，100個(gè)，還沒寫過，不過想象中應(yīng)該有，大型的復(fù)雜系統(tǒng)。
2是保持方法最小，一個(gè)方法只做一件事。
3是給方法取個(gè)好名字，好名字用處太大了，呵呵呵，特別是別人看別人的代碼時(shí)，特別是過了一段時(shí)間以后，再來看寫的代碼，特別是系統(tǒng)比較大比較復(fù)雜時(shí)，我們的腦子沒計(jì)算機(jī)好使。
4是保持類的數(shù)量最小，有時(shí)間看看極限編程的東西。這句話好象和第一句話有點(diǎn)矛盾，類的數(shù)量少了，類就變大了，類變小了，類的數(shù)量多了，呵呵，這可能具體情況具體分析吧，讓它們之間達(dá)到個(gè)平衡點(diǎn)，教程上一句話說的好：在不影響清晰度的情況下盡量的減少類。
5是保持注釋的數(shù)量最少，我剛剛看到這一點(diǎn)的時(shí)候，有點(diǎn)吃驚，因?yàn)槲矣龅降睦蠋煻脊膭?lì)我們有良好的注釋習(xí)慣，而且是邊寫代碼邊加注釋，而不是寫完代碼后統(tǒng)一再加注釋，總之是強(qiáng)烈建議寫注釋的，因?yàn)檫@樣便于閱讀代碼，而這里建議我們保持注釋最少，理由是，當(dāng)更新代碼時(shí)維護(hù)代碼時(shí)還要同時(shí)更新注釋，因?yàn)槟切┳⑨屚瑫r(shí)也過期了，這回徒增工作量，解決辦法是盡可能的使代碼清晰。經(jīng)可能的，想盡一切辦法的。
6是一致的代碼風(fēng)格，C# C++的代碼風(fēng)格好象和java的不太一樣。有人喜歡習(xí)慣這樣有人喜歡那樣。
7是避免switch.優(yōu)先用if,然后再switch.
8是public的,有足夠的理由不是public的,呵呵/作者把最有爭(zhēng)議性的放在了最后.
9是追隨Fower,這是個(gè)人名,寫了本書叫Refactoring,因式分解呵呵,查了查chinpub，中文版叫《重構(gòu)：改善既有代碼的設(shè)計(jì)》，明天去逛逛書店。
引用作者的一句話
"
編寫 Java 代碼相當(dāng)簡(jiǎn)單。編寫優(yōu)良的 Java 代碼則是一門手藝。傾力成為一個(gè)手藝人。
"