一、爲何要注重編程格式
今天，Java已成爲軟件開發的主流用語，筆者近來看到這樣一個統計結果：在商業軟件產品中，軟件產品的後續成本中約80%用於維護開銷。而軟件維護往往很少由原創者擔任，良好的源碼編寫風格有益於日後軟件維護已成爲諸軟件商公認的事實。
當今，軟件產品早己步入團隊協作式開發模式，要成爲一支優秀開發組的關鍵因素之一就是組員之間的密切交流，它體現在整個開發週期，從需求、計劃、測試案例、設計，到算法、實現方式等軟件工程各階段當中。具體到每一個實現模塊的源代碼亦不例外。簡言之，就是你在編寫這段代碼時應當讓其他人清晰的瞭解這段代碼“是什麼”，當程序出錯時，其他人能夠從程序邏輯上迅速分析找到錯誤出處。
二、講究細節
就程序應具有的“透明性”而言，開發小組應當採用一種共同的編寫格式。比如Java，大家應當採用同一種IDEs (Integrated Developer Environments)。自2000年以來，Java開發所用IDE發展基本成型，開發人員一致採用的平臺通常都是可免費下載的Sun公司的Netbeans IDE和Eclipse IDE，這兩種工具都是優秀的“格式化”工具，有助於開發組形成良好的編程風格。如果有人至今還固執地採用那種原始的文本編輯器輸入Java代碼，未免顯得愚鈍。
在我們輸入源代碼時，一個容易忽略的問題是代碼顯示。傳統的代碼行通常限制的字符數是80，這主要是考慮到最低廉的文本終端80x25顯示模式，這種思維在21世紀寬屏時代早已過時。今天的每行代碼字符默認值達120。在輸入代碼時我們遇到的一個心理活動就是用空格還是製表符Tab，一個Tab等於幾個空格，現在的答案是4個空格。
在Java中，從基本語法（比如while, do, for 等循環語句和類定義）開始就涉及到大括號，那麼這些括號的擺放位置即便是專業程序也具有不同風格，這裏例舉如下：
// K&R風格
if (condition) {
statement;
statement;
}
//Allman風格
if (condition)
{
statement;
statement;
}
//Whitesmiths Style風格
if (condition)
{
statement;
statement;
}
//GNU風格
if (condition)
{
statement;
statement;
}
究竟哪種格式好？維基百科論壇對此曾有過較長時間的討論，結果多數人傾向於前兩種格式。如果留心的話，你會看到在Sun公司網站和手冊中的代碼都採用了K&R風格。一次在做項目時，多數同事都採用了Allman風格，當我發現這點時編寫的代碼總量已達數千行，此時如果爲此而逐行修改不是怕耗時而是進度不允許，此時幸好我採用的Eclipse提供了格式配置工具遂即刻搞掂。流行的Java編輯器在輸入左括號時都會自動出現對應的右括號。
在代碼的控制結構中，假如只有一行執行語句，從語法上講，此時的大括號可以省略，但依筆者的經驗，此舉其實不明智，試想假如在後續編程時需在控制結構中新增加語句時，對控制結構的界限即便是作者本人有時也會混淆，所以，更爲穩妥的編寫風格是即便是隻有單行語句的控制結構也應當寫入一對並不多餘的大括號，樣例如下：
... 不好的習慣 ...
if (condition)
statement;
... 它可能造成的後果是...
if (condition)
statement;
statement;
儘管從語法上講，將多條語句放在同一行上不會出錯，但這亦屬不良習慣，因爲當他人對該語句進行復制/粘帖等編輯時容易搞錯。另一方面，對於一行容不下的超長語句，那麼續行應當有明顯的凹進，並保證詞組的完整性，其形式如下：
if (some really long condition that you need
to continue here)
{
statement;
statement;
}
再如：
...
com.acme.foo.project.data.YourObjectFactory objFactory =
new com.acme.foo.project.data.YourObjectFactory();
...
當用到超長的條件表達式，有時爲了邏輯清晰起見，我們應善於對其進行必要的分解，將一行分解爲多行短句，例如：
... 原來的代碼語句是...
if (value != null && value.length() > 0 && (errCount = 0 ||
isIgnorable(currentError)))
{
... statements ...
}
... 將其分解爲...
boolean valueIsGood = (value != null && value.length() > 0);
boolean noErrors = (errCount = 0 || isIgnorable(currentError));
if (valueIsGood && noErrors)
{
... statements ...
}
Java代碼中的註釋語句分爲線型和塊狀，雖然筆者習慣使用前者，常用於描述一個變量的作用，但這種方式在網站論壇交流時會產生一種不良副作用，在網站上傳代碼時容易出現不連貫現象。防止出錯的方法是，在上傳代碼時之前一定要預覽顯示結果。
在Java的聲明機制中，應注意變量的聲明位置，對於靜態變量或常量，應當置於源碼文件的頂部，這種風格來源於C語言。但Java對傳統C的一種明顯突破是，方法級變量是在需要時即時聲明和初始化，其合理性在於我們不必勞神聲明太多的類變量。
Java對類和變量的命名其實現在已形成了約定俗成：Types (類, 接口等)應當多用小寫字母，單詞間無空格，但每個單詞首字母要大寫，形如：SomethingLikeThis；非常量型變量的聲明則多用小寫字母，而且首字母要小寫，單詞間無隙，但從第二個單詞起則冠以大寫字母，形如somethingLikeThis。對於常量（Java中常用的對應關鍵字是final，也即'static'）在命名時通常皆由大寫字母組成，形如：SOMETHING_LIKE_THIS。所以，一段成熟的Java代碼在命名和拼寫時應當猶如以下樣碼：
class MyNeatClass
{
private int currentValue;
public static final String SOME_STRING_CONSTANT = "Blah blah";
...
public void doSomething()
{
...other statements...
...
int count=0;
for (loop condition)
{
if (branch condition)
{
count++;
}
}
...
}
}
新版Java出現的enum（“枚舉”）類型，看起來很象是特殊的class, 它也可以有自己的變量，可以定義自己的方法，可以實現一個或者多個接口。 當我們聲明一個enum類型時，定義通常是具有直觀意義的字符串，比如：
enum MyFirstEnum
{
ALPHA,
BETA,
GAMMA,
DELTA;
}
此外，Java編譯器對於源文件的調用具有優先級標準，我們在編寫代碼時須遵循這一規則，具體次序爲：項目所需的頭文件，包聲明語句，引入語句，type聲明以及"extends"項及"implements"，類變量，類方法，內部類聲明。
三、小結
本文從Java基本語法入手，列舉了Java良好編程風格所應體現的各種規範和規則細節。也許有人會有小題大做之感，但筆者積多年的編碼體會是，編寫代碼越多固然有利於編程技藝的提高，但規範的編程習慣將使寫出的代碼更便於分析和調試，這對於代碼的優質運行將善莫大焉；一個軟件項目的成功需要每個開發成員從自己做起，從每一行Coding開始。
