開門見山地說吧，在逛 GitHub 的時候，發現了一個非常有意思的項目，地址如下所示：
https://github.com/trekhleb/state-of-the-art-shitcode
名叫“垃圾代碼書寫準則”，瞧這名字，我真的是服了。作者也是良苦用心，從反面教材的角度來闡述正確書寫代碼格式的重要性。作者使用 JavaScript 編寫的代碼示例，我把它重製成了 Java 版，並且用我自己的語言風格翻譯成了中文，希望小夥伴們能夠喜歡。
💩 以一種容易造成代碼混淆的方式命名變量
命名越短，就需要越多的時間去思考代碼邏輯等問題。
Good 👍🏻
int a = 42;
Bad 👎🏻
int age = 42;
💩 變量/方法命名風格不統一
爲風格不統一干杯。
Good 👍🏻
int wWidth = 640;
int w_height = 480;
Bad 👎🏻
int windowWidth = 640;
int windowHeight = 480;
💩 不寫註釋
反正沒人能讀懂你的代碼。
Good 👍🏻
int cdr = 700;
Bad 👎🏻
註釋應該包含一些“爲什麼”，而不是一些“是什麼”。如果代碼連是“什麼”都表達不清楚，那代碼也太爛了。
// 700ms 的數量是從 UX A/B 測試結果中得到的一個經驗值。
// @查看: <詳細解釋 700 的一個鏈接>
int callbackDebounceRate = 700;
💩 使用母語寫註釋
如果你的母語是英語，那麼請忽略這條準則。
Good 👍🏻
// Закриваємо модальне віконечко при виникненні помилки.
toggleModal(false);
Bad 👎🏻
// 隱藏錯誤彈窗
toggleModal(false);
PS：如果英語書寫能力不是很強的話，建議還是用母語吧。畢竟說清楚總比說不清楚要強。
💩 聲明變量的風格不統一
再次爲風格不統一干杯。
Good 👍🏻
String [] i1 = {"沉", "默", "王", "二"};
String i2 [] = {"沉", "默", "王", "三"};
Bad 👎🏻
String [] wanger = {"沉", "默", "王", "二"};
String wangsan [] = {"沉", "默", "王", "三"};
💩 儘可能把代碼寫成一行
Good 👍🏻
IntStream.range(1, 5).boxed().map(i -> { System.out.print("Happy Birthday "); if (i == 3) return "dear NAME"; else return "to You"; }).forEach(System.out::println);
Bad 👎🏻
for (int i = 1; i < 5; i++) {
System.out.println("Happy Birthday " + (i == 3 ? "dear NAME" : "to you"));
}
💩 對錯誤信息不管不顧
無論什麼時候發現錯誤，都沒有必要讓其他人知道。
Good 👍🏻
try {
// 意料之外的情況。
} catch (error) {
// tss... 🤫
}
Bad 👎🏻
try {
// 意料之外的情況。
} catch (error) {
// and/or
logError(error);
}
💩 使用大量的全局變量
全球化的原則。
Good 👍🏻
int x = 5;
void multi() {
x = x * 2;
}
multi(); // 現在 x 是 10
Bad 👎🏻
int x = 5;
int multi(int num) {
return num * 2;
}
x = multi(x); // 現在 x 是 10
💩 聲明根本不會使用的變量
萬一以後用了呢？以備不時之需。
Good 👍🏻
int sum(int a, int b, int c) {
int timeout = 1300;
int result = a + b;
return a + b;
}
Bad 👎🏻
int sum(int a, int b) {
return a + b;
}
💩 如果條件允許的話，從不指定類型。
Good 👍🏻
// 享受便捷的快樂
List list = new ArrayList();
list.add("沉默王二");
list.add(18);
Bad 👎🏻
List<String> nameList = new ArrayList<String>();
// 編譯出錯
nameList.add(18);
💩 沒鳥用的代碼
看起來更嚴謹，其實很多餘。
Good 👍🏻
Integer multi(Object num) {
if (!(num instanceof Integer)) {
return null;
} else if (num != null) {
return (Integer) num * 2;
}
return null;
}
Bad 👎🏻
Integer multi(Object num) {
if (num instanceof Integer) {
return (Integer) num * 2;
}
return null;
}
💩 大量的 if-else 嵌套
Good 👍🏻
void someMethod(int a, int b, int c) {
if (a > 0) {
if (b > 0) {
if (c > 0) {
int result = a / b / c;
}
}
}
}
Bad 👎🏻
void someMethod1(int a, int b, int c) {
if (a < 0 || b < 0 || c < 0) {
return;
}
int result = a / b / c;
}
💩 參差不齊地縮進
參差不齊乃幸福本源。
Good 👍🏻
String [] wanger = {"沉",
"默", "王", "二"};
String [] wangsan = {"沉", "默", "王", "三"};
Arrays.asList(wanger).stream().
forEach(System.out::println);
Arrays.asList(wangsan).
stream().
forEach(System.out::println);
Bad 👎🏻
String [] wanger = {"沉", "默", "王", "二"};
String [] wangsan = {"沉", "默", "王", "三"};
Arrays.asList(wanger)
.stream()
.forEach(System.out::println);
Arrays.asList(wangsan)
.stream()
.forEach(System.out::println);
💩 代碼行數多的方法的比少的好
不要把代碼邏輯分成可讀的部分。
- 一個類中的代碼行數超過 10000 行。
- 一個方法中的代碼行數超過 1000 行。
- 一個方法裏既做減法處理又做加法處理，還做乘除的處理。
💩 不要測試你的代碼
代碼測試是測試工程師的事，關我屁事。
💩 避免代碼風格統一
隨心所欲地編寫代碼，特別是在一個團隊中有多個開發人員的情況下，我崇尚“自由”。
💩 不要寫文檔
從一開始就不要。
💩 不要刪除廢棄掉的代碼
代碼儘管已經廢棄了，註釋掉就行了，沒必要刪掉。
好了，小夥伴們還有需要補充的嗎？
喜歡逛 GitHub 的小夥伴們可以點擊下面的地址跳轉過去查看，我已經提交了：
https://github.com/itwanger/state-of-the-art-shitcode/blob/master/README.zh-CN.md