在 GitHub 上有一個新項目，它描述了「最佳垃圾代碼」的十九條關鍵準則。從變量命名到注釋編寫。這些準則將指導你寫出最亮眼的爛代碼。

為了保持與原 GitHub 項目一致的風格，下文沒有進行轉換。讀者們可以以相反的角度來理解所有觀點，這樣就能完美避免寫出垃圾代碼。

當然，以下十九條垃圾代碼書寫準則并沒有面面俱到，如果讀者們發現有一些難以忍受的爛代碼習慣，也可以留言發表你的看法。

這是一個你的項目應該遵循的垃圾代碼書寫準則的列表：

以一種代碼已經被混淆的方式命名變量

如果我們鍵入的東西越少，那么就有越多的時間去思考代碼邏輯等問題。

變量/函數混合命名風格

為不同慶祝一下。

Good

let wWidth = 640;
let w_height = 480;

Bad

let windowWidth = 640;
let windowHeight = 480;

不要寫注釋

反正沒人會讀你的代碼。

Good

const cdr = 700;

Bad

更多時候，評論應該包含一些“為什么”，而不是一些“是什么”。如果“什么”在代碼中不清楚，那么代碼可能太混亂了。

// 700ms的數量是根據UX A/B測試結果進行經驗計算的。
// @查看: <詳細解釋700的一個鏈接>
const callbackDebounceRate = 700;

使用母語寫注釋

如果您違反了“無注釋”原則，那么至少嘗試用一種不同于您用來編寫代碼的語言來編寫注釋。如果你的母語是英語，你可能會違反這個原則。

Good

// Закрива?мо модальне в?конечко при виникненн? помилки.
toggleModal(false);

Bad

// 隱藏錯誤彈窗
toggleModal(false);

盡可能混合不同的格式

為不同慶祝一下。

Good

let i = ['tomato', 'onion', 'mushrooms'];
let d = [ "ketchup", "mayonnaise" ];

Bad

let ingredients = ['tomato', 'onion', 'mushrooms'];
let dressings = ['ketchup', 'mayonnaise'];

盡可能把代碼寫成一行

Good

document.location.search.replace(/(^?)/,'').split('&').reduce(function(o,n){n=n.split('=');o[n[0]]=n[1];return o},{})

Bad

document.location.search
  .replace(/(^?)/, '')
  .split('&')
  .reduce((searchParams, keyValuePair) => {
    keyValuePair = keyValuePair.split('=');
    searchParams[keyValuePair[0]] = keyValuePair[1];
    return searchParams;
  },
  {}
)

不要處理錯誤

無論何時發現錯誤，都沒有必要讓任何人知道它。沒有日志，沒有錯誤彈框。

Good

try {
  // 意料之外的情況。
} catch (error) {
  // tss... 
}

Bad

try {
  // 意料之外的情況。
} catch (error) {
  setErrorMessage(error.message);
  // and/or
  logError(error);
}

廣泛使用全局變量

全球化的原則。

Good

let x = 5;

function square() {
  x = x ** 2;
}

square(); // 現在x是25

Bad

let x = 5;

function square(num) {
  return num ** 2;
}

x = square(x); // 現在x是25

創建你不會使用的變量

以防萬一。

Good

function sum(a, b, c) {
  const timeout = 1300;
  const result = a + b;
  return a + b;
}

Bad

function sum(a, b) {
  return a + b;
}

如果語言允許，不要指定類型和/或不執行類型檢查。

Good

function sum(a, b) {
  return a + b;
}

// 在這里享受沒有注釋的快樂
const guessWhat = sum([], {}); // -> "[object Object]"
const guessWhatAgain = sum({}, []); // -> 0

Bad

function sum(a: number, b: number): ?number {
  // 當我們在JS中不做置換和/或流類型檢查時，覆蓋這種情況。
  if (typeof a !== 'number' && typeof b !== 'number') {
    return undefined;
  }
  return a + b;
}

// 這個應該在轉換/編譯期間失敗。
const guessWhat = sum([], {}); // -> undefined

你應該有不能到達的代碼

這是你的 “Plan B”.

Good

function square(num) {
  if (typeof num === 'undefined') {
    return undefined;
  }
  else {
    return num ** 2;
  }
  return null; // 這就是我的"Plan B".
}

Bad

function square(num) {
  if (typeof num === 'undefined') {
    return undefined;
  }
  return num ** 2;
}

三角法則

就像鳥巢，鳥巢，鳥巢。

Good

function someFunction() {
  if (condition1) {
    if (condition2) {
      asyncFunction(params, (result) => {
        if (result) {
          for (;;) {
            if (condition3) {
            }
          }
        }
      })
    }
  }
}

Bad

async function someFunction() {
  if (!condition1 || !condition2) {
    return;
  }
  
  const result = await asyncFunction(params);
  if (!result) {
    return;
  }
  
  for (;;) {
    if (condition3) {
    }
  }
}

混合縮進

避免縮進，因為它們會使復雜的代碼在編輯器中占用更多的空間。如果你不喜歡回避他們，那就和他們搗亂。

Good

const fruits = ['apple',
  'orange', 'grape', 'pineapple'];
  const toppings = ['syrup', 'cream', 
                    'jam', 
                    'chocolate'];
const desserts = [];
fruits.forEach(fruit => {
toppings.forEach(topping => {
    desserts.push([
fruit,topping]);
    });})

Bad

const fruits = ['apple', 'orange', 'grape', 'pineapple'];
const toppings = ['syrup', 'cream', 'jam', 'chocolate'];
const desserts = [];

fruits.forEach(fruit => {
  toppings.forEach(topping => {
    desserts.push([fruit, topping]); 
  });
})

不要鎖住你的依賴項

以非受控方式更新每個新安裝的依賴項。為什么堅持使用過去的版本，讓我們使用最先進的庫版本。

Good

$ ls -la

package.json

Bad

$ ls -la

package.json
package-lock.json

函數長的比短的好

不要把程序邏輯分成可讀的部分。如果IDE的搜索停止，而您無法找到所需的文件或函數，該怎么辦？

一個文件中10000行代碼是OK的。

一個函數體有1000行代碼是OK的。

在一個‘ service.js ’ 中處理許多服務（第三方庫和內部庫、一些工具、手寫的數據庫ORM和jQuery滑塊）？ 這是OK的。

不要測試你的代碼

這是重復且不需要的工作。

避免代碼風格統一

編寫您想要的代碼，特別是在一個團隊中有多個開發人員的情況下。這是“自由”原則。

構建新項目不需要 README 文檔

一開始我們就應該保持。

保存不必要的代碼

不要刪除不用的代碼，最多注釋掉。