1. 前言
在程式設計中，風格不是關於時尚，而是關乎生存。Java 是一門由龐大團隊使用的語言，如果每個人都按「自己的習慣」來寫，專案很快就會變成一堆彼此不相連的碎片，只有作者本人看得懂（而且也不一定）。
程式碼風格是一組讓所有人都能同樣順暢閱讀程式碼的規則。就像交通標誌：如果忽視它們，行車很快就會陷入混亂。
為什麼這很重要？
- 可讀性：程式碼被閱讀的次數遠多於被撰寫的次數。糟糕的風格就像醫生潦草的字跡：誰也看不懂寫了什麼。
- 可維護性：若程式碼遵循規範，就更容易修改，也較不容易不小心把什麼弄壞。
- 協作：在團隊中，大家應該能不必多費口舌就互相理解。
- 工具：當風格統一，自動格式化器與程式碼分析工具的效果更好。
2. 程式碼風格的主要錯誤（以及如何避免）
縮排與大括號未遵循規範
錯誤：
沒有縮排且大括號混亂的程式碼，對眼睛和大腦都是折磨。
if(x>0){
System.out.println("x 是正數");
}else{
System.out.println("x 不是正數");
}
正確做法：
if (x > 0) {
System.out.println("x 是正數");
} else {
System.out.println("x 不是正數");
}
說明：
每一層縮排使用四個空格（這是 Java 的標準）。除非整個團隊另有共識，否則請避免使用 Tab。
不良的變數、方法與類別命名
錯誤：
int a = 5;
String s = "Vasya";
void f() { /* ... */ }
正確做法：
int age = 5;
String userName = "Vasya";
void printReport() { /* ... */ }
說明：
名稱應具備語意，能反映變數或方法的本質。
- 類別名稱首字母大寫，CamelCase：UserAccount。
- 方法與變數以小寫開頭，camelCase：calculateSalary、userList。
過長的方法與類別
錯誤：
100 行的方法、1000 行的類別——對維護來說是真正的 nightmare mode。
正確做法：
每個方法應只做一件事且保持精簡（理想情況是能完整顯示在一個螢幕上）。類別也不該膨脹到像《戰爭與和平》那麼長。
範例：
不好：
public void processOrder() {
// 200 行程式碼
}
好：
public void processOrder() {
validateOrder();
calculateTotal();
saveToDatabase();
sendEmailConfirmation();
}
使用「魔術數字」與字串
錯誤：
if (status == 42) {
// ...
}
正確做法：
public static final int STATUS_APPROVED = 42;
if (status == STATUS_APPROVED) {
// ...
}
說明：
請以常數（static final）取代「魔術」數字與字串。在較新的 Java 版本中也有 enum——對於有限集合的值請使用它們。
註解：缺失或過度
錯誤 1：
完全沒有註解——複雜的程式碼讓人看不懂做了什麼。
錯誤 2：
對每個動作都加註解，甚至連顯而易見的也加。
// 將 x 增加 1
x = x + 1;
// 檢查 x 是否等於 10
if (x == 10) {
// ...
}
這種註解只會礙事！僅針對複雜或不明顯的部分加註解。理想情況下，好的程式碼不靠註解也應該能理解——註解應用來解釋「為什麼」，而不是「做什麼」。
// 考慮 VIP 客戶的折扣
double total = calculateTotalWithDiscount();
3. Java 慣例：專業人員的寫法
在 Java 中有官方與事實上的排版標準。Oracle Java Code Conventions 與 Google Java Style Guide 是最常見的兩套。
縮排與大括號
開啟的大括號與宣告放在同一行：
public void print() {
// ...
}
每一層縮排使用四個空格。
命名
- 類別與介面：以大寫開頭的 CamelCase（Person、UserAccount）。
- 方法與變數：以小寫開頭的 camelCase（calculateSalary、userList）。
- 常數：全部大寫並用底線分隔（MAX_SIZE、DEFAULT_TIMEOUT）。
- 套件：僅使用小寫，可用點號分隔（com.example.project）。
空白
在運算子兩側與逗號之後保留空白：
int sum = a + b;
System.out.println(name, age);
左括號後與右括號前不要加空白：
if (x > 0) { ... }
每行長度
建議每行不要超過 100–120 個字元。（對，你的螢幕很大，但當程式碼不會延伸到遙遠的右方時，閱讀體驗會更好。）
類別成員宣告順序
建議的順序（依 Oracle）：
- 欄位（先 static，再一般）
- 建構子
- 方法
範例：
public class User {
private static int userCount;
private String name;
public User(String name) {
this.name = name;
userCount++;
}
public String getName() {
return name;
}
}
4. 範例：重構糟糕的風格
以下是一個在野外可能會遇到的類別：
class person{String n;int a;void p(){System.out.println(n+" "+a);}}
某個辦公室裡，這段程式碼讓一位 Java 開發者落淚。
讓我們把它改善：
public class Person {
private String name;
private int age;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
public void print() {
System.out.println(name + " " + age);
}
}
改了哪些地方：
- 類別與成員使用了正確的存取修飾子。
- 命名具備語意且易讀。
- 每個類別成員各占新的一行。
- 使用建構子進行初始化。
- 欄位設為 private，以符合封裝。
5. 實用細節
自動格式化器
現代 IDE（IntelliJ IDEA、Eclipse、VS Code）都能依照規範自動格式化程式碼。
快捷鍵：
- IntelliJ IDEA：Ctrl + Alt + L
- Eclipse：Ctrl + Shift + F
靜態分析
Checkstyle、SonarLint、PMD 等工具能在程式執行前就揪出風格違規與潛在錯誤。
實際效果：
- 如果你的變數名是 x 而不是 userAge，Checkstyle 會抱怨。
- 如果方法過長或類別違反 SOLID 原則，SonarLint 會提出建議。
職責分離與「乾淨」程式碼
- 每個類別只負責一件事（Single Responsibility Principle）。
- 別害怕建立額外的類別與方法——這不是「膨脹」，而是在體恤未來的讀者。
- 盡量避免重複的程式碼：若看到兩段相似的片段——抽成獨立方法。
常數與「魔術數字」：正確做法
不要這樣：
double price = 100 * 0.18;
改成這樣：
public static final double VAT_RATE = 0.18;
double price = 100 * VAT_RATE;
如果常有固定的值集合——請使用 enum：
public enum Status {
NEW, IN_PROGRESS, DONE
}
6. 常見的風格與可讀性錯誤
錯誤 №1：忽視 code conventions。
如果團隊沒有統一風格，程式碼很快就會變得難以閱讀且難以維護。即便你是單兵作業，一年後的你也會感謝現在的自己。
錯誤 №2：名字太短/太長。
變數 a 或 temp——不好。變數 theCurrentUserNameThatIsUsedForAuthorizationInTheSystem——也不建議。請拿捏平衡：userName、age、bookList。
錯誤 №3：「魔術數字」。
把數字與字串直接寫在程式碼中會妨礙維護，還會提高出錯機率。
錯誤 №4：龐大的方法與類別。
方法越大，越難測試與理解。請將其拆分為合乎邏輯的部分。
錯誤 №5：糟糕的類別結構。
欄位東一塊西一塊，方法宣告順序隨機——這些都會讓人難以快速找到重點。
錯誤 №6：註解過多或缺失。
在 int x = 0; 旁邊寫「初始化變數」沒有必要。能解釋複雜商業邏輯的註解——非常必要。
錯誤 №7：格式化不一致。
專案的一處用四個空格，另一處用 Tab；這裡大括號換行，那裡不換。這看起來邋遢，還會惹惱同事。
GO TO FULL VERSION