笑着 胖胖蘭原創，轉載請註明。
[email protected]<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
http://blog.csdn.net/bluesmile979/archive/2008/10/18/3097197.aspx
學習大多數語言剛開始的時候要接觸到的東西都是差不多的。命名空間，訪問權限，類，方法，屬性，加減乘除的數學運算，接收鍵盤輸入，輸出到控制檯。這些就是所謂的3天會走5天會跑7天會飛中能夠學到的大部分的內容。學習了這些就可以開始編寫一些程序，做一些聯繫，甚至緊急狀況下頂一下，做一些低端的開發工作。當然，這篇文章並不是這些基礎知識的教程，那些3天會走5天會跑7天會飛的教程網絡上有很多，寫得都挺好的，可以隨便找一本來學習。而且笑着本人推薦先找一本這樣的書來學習一下。整體瞭解一下這一門語言大概是怎麼樣的，可以快速的開始我們的第一個非HelloWord程序。
這篇文章要討論的，是關於高質量編程方面的。高質量編程將要貫穿我們的整個職業生涯，能在學習開始的時候有個不錯的開始，那麼對未來的發展將會產生不可估量的好處。高質量編程一般是從可讀性，可靠性，高效率，代碼結構，重用性，使用適當的底層功能等等方面來考慮代碼是否優秀。學習了一門語言的基礎語法時候，主要涉及到的就是代碼的可讀性，其他方面需要對一門語言的深入瞭解。目前一般討論這些問題的書籍文章都是分開的，技術就是技術，技術OK了，站在一個較高的高度來回頭學習高質量編程。但是這樣的缺點就是習慣養成了不太好改，很多人就不會再重視高質量編程這方面的事情。而且習慣的養成需要時間，先學好技術，然後回頭重視程序質量這並不是一個好的學習方式。但是要提高某方面的程序質量又必須有相應的技術基礎，所以笑着這個系列的文章打算從另外一個角度，按照學習的不同階段來慢慢涉及到高質量編程以及其他種種注意事項的方方面面。會在後面的文章中慢慢討論。
好了，下面我們來看看學會了Java的基礎語法之後，我們應該，可以注意些什麼。當然，所有的一切努力都是爲了讓您的代碼美觀，易讀，高效，易維護。請牢記我們的目的，規矩不是死的，這裏只是給出一些建議。事實上，每一個觀點具體如何做好都曾經，或者還在引起廣泛的討論。笑着掌握的也許不是最新的。而且每個公司都會有自己的開發標準。適合自己的，纔是最好的。記住我們的目的，其他人能夠給你的，只是建議，參考。
首先，是一些基礎的規範。大家也許已經知道，簡單介紹一下。
1． 良好的命名。包括，
a. 類，函數，變量的名稱要儘量體現出其所具有的功能。單詞之間用大小寫，下劃線等明確區分。
b. 全局變量，局部變量，函數參數有明確的區分。比如函數的參數採用下劃線開頭的寫法等。（一些編譯器會自動採用不懂得顏色來幫忙區別，比如RAD）
c. 常量與變量有明確區別，比如常量所有字符大寫。
d. 表明變量數據類型，比如nInput，strInput。這一點，曾經是C++裏面經典的規範，但是Java世界裏這條規範沒有引起太廣泛的共鳴。就個人喜好來講，小這是比較喜歡這個規範的。
e. 儘量不要定義相同的類名。雖然不同的包下允許使用相同的類名，但是兩個同樣的名稱爲User類，會給自己帶來不必要的麻煩。比如Java裏面就有java.util.Date和java.sql.Date，這會給我們編程的時候造成困擾。所以不要認爲不會出現這種情況。很容易，你就會“不小心”的定義兩個同名的類。這多少是個設計上的問題，已經超出了基礎的範圍。
2． 區分你的代碼塊兒。
a. 把你的類的屬性統一定義到類的開始或者結束的位置。現在應該很少人把類的屬性跟類的方法穿插定義了。存在特殊情況，但是這裏不想討論。
b. 把你的屬性，或者方法，按照訪問權限不同來順序定義。比如先定義public的屬性（這裏是舉個例子，原則上是不推薦定義public屬性的），然後protected的屬性，然後private的屬性，然後public的方法。。。。。以此類推。之所以這樣，是因爲代碼閱讀的時候會更加關心接口部分，也就是public出來，公開給別人部分的代碼會更加引起關注。
c. 把同種類別的屬性（方法）定義在一起，用換行來明確分隔。比如：
// 用戶信息
private String a;
private String b;
private String c;
// 業務信息
private String d;
private String e;
private String f;
不分塊兒的話就會很難快。效果如下：
private String a;
private String b;
private String c;
private String d;
private String e;
private String f;
d. 關於函數內使用的局部變量的定義，現在函數開始的地方統一定義，然後開始業務處理。這一條曾經爭議非常大，因爲存在另外一條矛盾的規則，儘量讓你定義的變量保持最小的作用範圍。不知道現在有什麼結論。笑着的傾向是儘量遵守這個規則，但是可以根據具體情況將少量的變量定義在使用開始的地方。或則折衷一點每一個作用範圍開始的地方定義所有的變量。這也許需要根據具體情況來採取不同的策略。
e. 函數內每一段相對獨立的業務邏輯結束之後用換行來分割一下。參照c.把同種類別的屬性（方法）定義在一起，用換行來明確分隔。
3． 適當的縮進，空格，對齊。
a. 適當的縮進。現在編譯器應該都提供這個格式化功能了。但是這裏有一個問題，縮進，你是用4個空格好呢？還是用Tab好呢？知道我再說什麼？不同的IDE對於Tab的長度的解釋是不一樣的，它默認是4個空格，但是有的IDE可能把它定義爲8個空格，程序員可能有的時候用Tab，有的時候用4個空格。於是乎，當你換一個IDE來看統一份代碼的時候。。。。。天下大亂了。。。。。
b. 適當的空格，比如
a=a+1;
a = a+1;
a = a + 1;
哪一種看起來比較舒服？最後一種被採用的比較多。第二種也不錯。第一種？有可能你需要調整一下自己的審美觀點以保持跟大衆的審美觀一致。
c. 適當的對齊。一般出現在類的屬性定義的時候。比如:
對齊前：
private String abc = “1”;
private String abcd = “1”;
private String abcde = “1”;
對齊後：
private String abc = “1”;
private String abcd = “1”;
private String abcde = “1”;
有一些極端喜歡對齊的人存在。但是笑着個人觀點，差不多就可以了。屬性定義這裏會非常有效果，其他的地方，自己看着辦就好了。
4． 適當的列數。
適當的列數。當一行代碼太多會影響閱讀。從前一般定義列數不要超過80，現在因爲種種原因，也有定義到120的。跟這一條相關的一個規則就是不要在函數調用中欠套過多的函數調用。比如,下面是一個反面例子。
g.draw(t.getText(s.getXXX(c.getXXX())));
下面列舉幾個其他的常見的例子。
例子1，函數參數過多。
反：
public void setXXX(String _param1, String _param2, String _param3, String _param4)
正：
public void setXXX(String _param1,
String _param2,
String _param3,
String _param4)
例子2，append
反：
s.append(a).append(b) .append(c) .append(d)
正：
s.append(a)
.append(b)
.append(c)
.append(d)
意思一下，類似的狀況很多。不在編譯器裏面代碼格式調整比較費勁不多舉了。
5． 適當的行數。
一個函數，一個類，應該提供相對單純的功能。如果你的函數，類的行數超過了一定的範圍。那麼一方面會影響到閱讀代碼時對代碼的理解。另外一方面，那麼多行的代碼，這裏肯定包含了過多的業務邏輯，耦合性加大對你的維護會帶來非常大的麻煩。
6． 善用常量
儘量用一些有意義的常量來代替無意義的數值。比如：
if(status == 0){}
就不如定義一個常量,比如int opened = 0;然後
if(status == opened){}
7． 不要過多的嵌套邏輯分支控制，比如
if(){
if(){
if(){
if(){
if(){
}
}
}
}
}
這樣的代碼會讓人很難讀懂你的程序。你自己回頭也很難讀懂自己的程序。發生錯誤的可能性，測試的複雜度也會相應大幅度增加。而且，嵌套這麼多層的話，你本身對業務需求的理解肯定或多或少的出了一些問題。最多嵌套3層左右也許是個比較合理的選擇。
基礎的，適用於任何開發語言的一些注意事項基本就是上面這麼多。在基礎之上，我們需要考慮一些語言特性。比如，
int i;
double a = 0;
for ( i = 0; i < 10 ;i++){
a = a + 0.1;
if (a == 1){
System.out.println("0.1加10次應該等於1" );
}
}
這裏期待值是0.1加10次應該等於1，但是實際上是不是這樣的呢？這段代碼預期值跟實際值是不是一樣的呢？
再比如String和StringBuffer,等等。
作爲結束，這裏先舉這個個例子。下一篇文章中會列舉一些常見的語言特性相關的問題來討論。好了，在進一步學習之前，我們可以把3天會走的教程扔掉了，去找一個詳細介紹Java的書籍把基礎打牢吧。
順便說一句，Java編程思想雖然是本好書，但是書裏面更多的是面向C++轉Java程序員的論述，可以考慮適當的忽略，如果你就是要做Java，那些佔了很大篇幅的論述對你可能不是那麼的重要。
附think in java3下載