# 變數、函數
---
## 變數 (Variables)
#### 具有意義且可讀性的名稱
糟糕的：

const yyyymmdstr = moment().format('YYYY/MM/DD');

適當的：

const currentDate = moment().format('YYYY/MM/DD');

實際的code(這個schema 可以定義物件裡面對應的欄位需要的型別...必填等等)：
可以如何更改？

 const schema = yup
    .object({
      brand: yup.string().required(),
      model: yup.string().required(),
      modbus_supper: yup.boolean().required().default(true),
      max_ai: yup.number().positive().required(),
      max_di: yup.number().positive().required(),
      max_do: yup.number().positive().required(),
      max_serial: yup.number().positive().required(),
      max_modbus_slave: yup.number().positive().required(),
      max_modbus_register: yup.number().positive().required(),
      has_iothub: yup.boolean().required().default(false),
      has_mqtt: yup.boolean().required().default(true),
    })
    .required();

---
#### 相同類型的變數使用相同的名稱
糟糕的：

 getUserInfo();
 getClientData();
 getCustomerRecord();

適當的：

getUser()

這邊其實我不太了解要表示什麼
我自己在實作上通常是這樣寫
就是比較類似他糟糕的寫法...

getUserInfo()
getProjectList()
...

---
#### 使用可解釋的變數
糟糕的：

const address = 'One Infinite Loop, Cupertino 95014';
const cityZipCodeRegex = /^[^,\\]+[,\\\s]+(.+?)\s*(\d{5})?$/;
saveCityZipCode(
  address.match(cityZipCodeRegex)[1],
  address.match(cityZipCodeRegex)[2]
);

適當的：

const address = 'One Infinite Loop, Cupertino 95014';
const cityZipCodeRegex = /^[^,\\]+[,\\\s]+(.+?)\s*(\d{5})?$/;
const [_, city, zipCode] = address.match(cityZipCodeRegex) || [];
saveCityZipCode(city, zipCode);

這樣的寫法就不用去猜，第一個是什麼，第二個是什麼，直接明確的定義出city 和 zipCode

---

#### 避免心理作用（Mental Mapping）
糟糕的：

const locations = ['Austin', 'New York', 'San Francisco'];
locations.forEach(l => {
  doStuff();
  doSomeOtherStuff();
  // ...
  // ...
  // ...
  // 等等，這 `l` 是…？
  dispatch(l);
});

適當的：

const locations = ['Austin', 'New York', 'San Francisco'];
locations.forEach(location => {
  doStuff();
  doSomeOtherStuff();
  // ...
  // ...
  // ...
  dispatch(location);
});

簡單來說就是清楚的寫好每一個變數名稱

---
#### 避免使用不必要的描述（Context）
抱歉我看不懂...
https://codepen.io/felixtt0201/pen/OJZGWNj?editors=1111

---

#### 使用預設參數（Parameter）代替條件判斷（Conditionals）
使用預設參數較整潔，但請注意，當參數為 undefined 時才會作用，其他種類的虛值（Falsy）不會，像是 ''、false、null、0、NaN 等。

糟糕的：

function createMicrobrewery(name) {
  const breweryName = name || 'Hipster Brew Co.';
  // ...
}

適當的：

function createMicrobrewery(name = 'Hipster Brew Co.') {
  // ...
}

我自己實作上比較少，這邊的必要性？
我自己覺得是可以 `selectedProjectInfo` 沒有值得時候防呆？
實際的code參考：

  const dynamicLink = (selectedProjectInfo) => {
    // CLOUD
    if (cloudId && tenantId) {
      return `/cloud/${cloudId}/tenant/${tenantId}/project/${selectedProjectInfo?.id}?portal=${portal}`;
    }
    // TENANT
    if (tenantId) {
      return `/tenant/${tenantId}/project/${selectedProjectInfo?.id}?portal=${portal}`;
    }
  };

### 小結
- 變數命名上，應該一看就知道代表的意思，不可隨意命名
-- 延伸的問題可能是，變數名稱越來越長 ex: `gatewaySpecList`....
- 變數命名上是否要對應 api 的回傳值？
-- https://aiotsupervisor.docs.apiary.io/#reference/0/vm/vm-(ui:supervisor)
- 可以有個小議題可以看看這會怎麼寫

const gateways =[...]
const gatewayList =[...]                 
gateways.map((gateway? item? info?)=>{
    console.log(...)
})
gatewayList.map((gateway)=>{
    console.log(...)
})

---
## 函數 (function)
#### 參數（Parameter） (少於 2 個較佳)
限制函數的參數數量非常重要，因為能讓你更容易地測試。過多的參數代表著過多的組合，會導致你不得不編寫出大量測試。

一個至二個是最理想的，盡可能避免大於三個以上。如果你有超過兩個以上的參數，代表你的函數做太多事情。如果無法避免時，可以有效地使用物件替代大量的參數。

糟糕的：

function createMenu(title, body, buttonText, cancellable) {
  // ...
}

適當的：

function createMenu({ title, body, buttonText, cancellable }) {
  // ...
}

createMenu({
  title: 'Foo',
  body: 'Bar',
  buttonText: 'Baz',
  cancellable: true
});

這邊滿有趣的，因為我認為就算包成物件，看起來是一個物件，但裡面也是很多個參數...這樣有比較好嗎？
只是目前在實務上很像很難避免，在React中，元件可能會這樣寫，
不管是哪種寫法，都需要再去看傳進來的這個變數在幹嘛...(是否用TS，去定義傳進來的參數能更快明白？)
只是第一種比較能清楚明白傳進來有哪些變數，不用再去猜

第一種
const Confirm = ({ getValues, previousStep, gatewaySpec, currentAction }) => {....}
or 
第二種
const Confirm = (props) =>{
    props.getValues...
    props.previousStep...
}

---

#### 一個函數只做一件事情（單一性）& 函數應該只做一層抽象（Abstraction）
1. 這是個非常重要的原則，當你的函數做超過一件事情時，它會更難以被撰寫、測試與理解。當你隔離（Isolate）你的函數到只做一件事情時，它能更容易地被重構（Refactor）與清晰地閱讀。如果嚴格遵守此項原則，你將會領先許多開發者。

2. 當你的函數需要的抽象多於一層時，代表你的函數做太多事情了。將其分解以利重用與測試。

糟糕的：

1. function emailClients(clients) {
  clients.forEach(client => {
    const clientRecord = database.lookup(client);
    if (clientRecord.isActive()) {
      email(client);
    }
  });
}

2. 
function parseBetterJSAlternative(code) {
  const REGEXES = [
    // ...
  ];

  const statements = code.split(' ');
  const tokens = [];
  REGEXES.forEach(REGEX => {
    statements.forEach(statement => {
      // ...
    });
  });

  const ast = [];
  tokens.forEach(token => {
    // lex...
  });

  ast.forEach(node => {
    // parse...
  });
}

適當的：

1-1.
function emailActiveClients(clients) {
  clients.filter(isActiveClient).forEach(email);
}

function isActiveClient(client) {
  const clientRecord = database.lookup(client);
  return clientRecord.isActive();
}

2-2.
function parseBetterJSAlternative(code) {
  const tokens = tokenize(code);
  const syntaxTree = parse(tokens);
  syntaxTree.forEach(node => {
    // parse...
  });
}

function tokenize(code) {
  const REGEXES = [
    // ...
  ];

  const statements = code.split(' ');
  const tokens = [];
  REGEXES.forEach(REGEX => {
    statements.forEach(statement => {
      tokens.push(/* ... */);
    });
  });

  return tokens;
}

function parse(tokens) {
  const syntaxTree = [];
  tokens.forEach(token => {
    syntaxTree.push(/* ... */);
  });

  return syntaxTree;
}

雖然筆者建議這樣，但可以探討的是，如果一個function能做完的，寫成兩個的優缺點是？

---

#### 函數名稱應該說明它做的內容
糟糕的：

function addToDate(date, month) {
  // ...
}

const date = new Date();

// 難以從函數名稱看出到底加入了什麼
addToDate(date, 1);

適當的：

function addMonthToDate(month, date) {
  // ...
}
const date = new Date();
addMonthToDate(1, date);

***譯者附註***：建議函數命名以動詞開頭，像是 doSomething()、setupUserProfile()。

簡單來說就是好好命名，然後看是否規範命名的方式，
以我現在`Nextjs`的專案，會有用`pages`資料夾裡面的檔案作為router，
所以在我的pages裡面的元件名稱後面都會以Page結尾，與一般的元件區分

---

#### 移除重複的（Duplicate）程式碼
絕對避免重複的程式碼，重複的程式碼代表者更動邏輯時，需要同時修改多處。
糟糕的：

function showDeveloperList(developers) {
  developers.forEach(developer => {
    const expectedSalary = developer.calculateExpectedSalary();
    const experience = developer.getExperience();
    const githubLink = developer.getGithubLink();
    const data = {
      expectedSalary,
      experience,
      githubLink
    };

    render(data);
  });
}

function showManagerList(managers) {
  managers.forEach(manager => {
    const expectedSalary = manager.calculateExpectedSalary();
    const experience = manager.getExperience();
    const portfolio = manager.getMBAProjects();
    const data = {
      expectedSalary,
      experience,
      portfolio
    };

    render(data);
  });
}

適當的：

function showEmployeeList(employees) {
  employees.forEach(employee => {
    const expectedSalary = employee.calculateExpectedSalary();
    const experience = employee.getExperience();

    const data = {
      expectedSalary,
      experience
    };

    switch (employee.type) {
      case 'manager':
        data.portfolio = employee.getMBAProjects();
        break;
      case 'developer':
        data.githubLink = employee.getGithubLink();
        break;
    }

    render(data);
  });
}

***譯者附註***：
剛讀完這個原則時，我非常遵守，但是個人龜毛的個性，造成了不少麻煩，我會在開發時不斷的思考是否會出現了重複的程式碼，甚至考慮到了之後的重用性。代價就是過度設計（Over Engineering）造成功能開發窒礙難行，設計了良好架構，但實際上並未被使用到。最後總結了一個建議作為附加原則：一開始撰寫程式碼先以功能開發優先，當你發現有兩個以上的地方重複時，再來考慮要不要重構。

這邊可以探討，不要做重複的事情，我相信是大家都會遵守的，只是哪個時機點和用在哪邊，
共用邏輯很好，但如果針對某個小部分他的邏輯要客製化，會怎麼做呢？

---

#### 不要使用旗標（Flag）作為參數
當你的函數使用了旗標當作參數時，代表函數做不只一件事情，依照不同旗標路徑切分你的函數。
糟糕的：

function createFile(name, temp) {
  if (temp) {
    fs.create(`./temp/${name}`);
  } else {
    fs.create(name);
  }
}

適當的：

function createFile(name) {
  fs.create(name);
}

function createTempFile(name) {
  createFile(`./temp/${name}`);
}

---

#### 使用 Object.assign 設定 Object 的預設值
p.s. Object.assign 支援大多的瀏覽器(ES6語法)，但少數還是不支援IE
糟糕的：

const menuConfig = {
  title: null,
  body: 'Bar',
  buttonText: null,
  cancellable: true
};

function createMenu(config) {
  config.title = config.title || 'Foo';
  config.body = config.body || 'Bar';
  config.buttonText = config.buttonText || 'Baz';
  config.cancellable =
    config.cancellable !== undefined ? config.cancellable : true;
}

createMenu(menuConfig);

適當的：

const menuConfig = {
  title: 'Order',
  body: 'Bar',
  buttonText: 'Send',
  cancellable: true
};

function createMenu(config) {
  let finalConfig = Object.assign(
    {
      title: 'Foo',
      body: 'Bar',
      buttonText: 'Baz',
      cancellable: true
    },
    config
  );
  return finalConfig;
  // config 現在等同於： {title: 'Order', body: 'Bar', buttonText: 'Send', cancellable: true}
  // ...
}

createMenu(menuConfig);

---

#### 避免副作用（Side Effects）
當函數作用在除了回傳值外的地方，像是讀寫文件、修改全域變數或是將你的錢轉帳到其他人帳戶，則稱為副作用。

程式在某些情況下是需要副作用的，像是上面所提到的例子。這時你應該將這些功能集中在一起，不要同時有多個函數或是類別同時操作資源，應該只用一個服務（Service）完成這些事情。

常見的問題像是：

在沒有任何架構下，同時多個物件中分享共有狀態。
可變的狀態，且可以被任何人寫入
副作用發生的地方沒有被集中。
如果你能避免這些問題，你會比大多數的工程師快樂。

糟糕的：

// 全域變數被以下函數使用
// 假如有其他的函數使用了這個名稱，現在他變成了陣列，將會被破壞而出錯。
let name = 'Ryan McDermott';

function splitIntoFirstAndLastName() {
  name = name.split(' ');
}

splitIntoFirstAndLastName();

console.log(name); // ['Ryan', 'McDermott'];

適當的：

function splitIntoFirstAndLastName(name) {
  return name.split(' ');
}

const name = 'Ryan McDermott';
const newName = splitIntoFirstAndLastName(name);

console.log(name); // 'Ryan McDermott';
console.log(newName); // ['Ryan', 'McDermott'];

從範例可以得知，原本的name從字串變成陣列，這種就會增加debug的難度

第二部分：

糟糕的：

const addItemToCart = (cart, item) => {
  cart.push({ item, date: Date.now() });
};

適當的：

const addItemToCart = (cart, item) => {
  return [...cart, { item, date: Date.now() }];
};

cart的值被改變了，會不知道原本的是cart是什麼

---

#### 別寫全域函數（Global Function）
在 JavaScript 中弄髒全域是個不好的做法，因為你可能會影響到其他函數庫或是 API。舉個例子，如果妳想要在 JavaScript 的原生陣列方法，擴展 diff 方法，用 B 陣列來去除 A 陣列中的元素（Element）。常見做法你可能會在 Array.prototype 中增加一個全新的函數，如果其他函數庫也有自己的 diff 實現的話將會互相影響。這就是為什麼我們需要使用 ES2015/ES6 的類別，來擴展的原因。
糟糕的：

Array.prototype.diff = function diff(comparisonArray) {
  const hash = new Set(comparisonArray);
  return this.filter(elem => !hash.has(elem));
};

適當的：

class SuperArray extends Array {
  diff(comparisonArray) {
    const hash = new Set(comparisonArray);
    return this.filter(elem => !hash.has(elem));
  }
}

這邊翻譯怪怪的，我認為是不要去使用原生或者框架給的API的名稱來命名自己的function
例如：
Vue 有 watch, mounted, computed...
React 有 useState,useEffect
基本上我們就不會拿以上的名稱去當作function name

---

#### 偏好使用函數式程式（Functional Programming）設計代替命令式程式設計（Imperative Programming）
JavaScript 不是像 Haskell 一樣的函數式語言，但它具有類似特性。函數式程式設計更加乾淨且容易被測試。當你在寫程式時，盡量選擇此設計方式。

糟糕的：

const programmerOutput = [
  {
    name: 'Uncle Bobby',
    linesOfCode: 500
  },
  {
    name: 'Suzie Q',
    linesOfCode: 1500
  },
  {
    name: 'Jimmy Gosling',
    linesOfCode: 150
  },
  {
    name: 'Gracie Hopper',
    linesOfCode: 1000
  }
];

let totalOutput = 0;

for (let i = 0; i < programmerOutput.length; i++) {
  totalOutput += programmerOutput[i].linesOfCode;
}

適當的：

const programmerOutput = [
  {
    name: 'Uncle Bobby',
    linesOfCode: 500
  },
  {
    name: 'Suzie Q',
    linesOfCode: 1500
  },
  {
    name: 'Jimmy Gosling',
    linesOfCode: 150
  },
  {
    name: 'Gracie Hopper',
    linesOfCode: 1000
  }
];

const totalOutput = programmerOutput.reduce(
  (totalLines, output) => totalLines + output.linesOfCode,
  0
);

這種寫法不知道是不是寫到測試才有感覺差異

---

#### 封裝狀態（Encapsulate Conditionals）
糟糕的：

if (fsm.state === 'fetching' && isEmpty(listNode)) {
  // ...
}

適當的：

function shouldShowSpinner(fsm, listNode) {
  return fsm.state === 'fetching' && isEmpty(listNode);
}

if (shouldShowSpinner(fsmInstance, listNodeInstance)) {
  // ...
}

我個人都是寫 糟糕的 那種，適當的 也看過，但目前沒有感覺的出來好處，有看過的壞處是
function name 亂命名根本不知道他是要判斷什麼，還要回去看那個 function的邏輯...
或者是共用同個function 然後忘記使用的地方，之後更改到共用的function 就全壞了...

#### 避免負面狀態（Negative Conditionals）
糟糕的：

function isDOMNodeNotPresent(node) {
  // ...
}

if (!isDOMNodeNotPresent(node)) {
  // ...
}

適當的：

function isDOMNodeNotPresent(node) {
  // ...
}

if (isDOMNodeNotPresent(node)) {
  // ...
}

這邊我也不太知道優點在哪，我是滿常寫糟糕的那種情況...

---

#### 避免狀態
當你第一次聽到時，這聽起來是不可能的任務。大部分的人會說：「怎麼可能不使用 if 語法？」事實上你可以使用多態性（Polymorphism） 達到相同的效果。第二個問題來了，「為什麼我們需要這樣做呢？」依據前面概念，為了保持程式碼的乾淨，當類別或是函數出現 if 語法，代表你的函數做了超過一件事情。記住，一個函數只做一件事情！
糟糕的：

class Airplane {
  // ...
  getCruisingAltitude() {
    switch (this.type) {
      case '777':
        return this.getMaxAltitude() - this.getPassengerCount();
      case 'Air Force One':
        return this.getMaxAltitude();
      case 'Cessna':
        return this.getMaxAltitude() - this.getFuelExpenditure();
    }
  }
}

適當的：

class Airplane {
  // ...
}

class Boeing777 extends Airplane {
  // ...
  getCruisingAltitude() {
    return this.getMaxAltitude() - this.getPassengerCount();
  }
}

class AirForceOne extends Airplane {
 // ...
  getCruisingAltitude() {
    return this.getMaxAltitude();
  }
}

class Cessna extends Airplane {
  // ...
  getCruisingAltitude() {
    return this.getMaxAltitude() - this.getFuelExpenditure();
  }
}

---

#### 避免型別（Type）檢查
1. JavaScript 為弱型別語言，代表函數應能處理任何型別的引數（argument）。有時這會帶給你一些麻煩，讓你需要做型別檢查。有很多方法可以避免這種問題發生，第一種就是統一所有的 API。

糟糕的：

function travelToTexas(vehicle) {
  if (vehicle instanceof Bicycle) {
    vehicle.pedal(this.currentLocation, new Location('texas'));
  } else if (vehicle instanceof Car) {
    vehicle.drive(this.currentLocation, new Location('texas'));
  }
}

適當的：

function travelToTexas(vehicle) {
  vehicle.move(this.currentLocation, new Location('texas'));
}

以範例1來說，我覺得就是確保傳入的參數是統一的型別或者類型

2. 假設你需要型別檢查原始數值，像是字串與整數且你無法使用多態性處理，考慮使用 TypeScript 吧。他是提供標準 JavaScript 靜態類型的的最佳選擇。手動型別檢查需要很多額外處理，你得到的是虛假的型別安全，且失去的可讀性。保持你的 JavaScript 程式碼的整潔、寫好測試與足夠的程式碼審查（Code Review）。如果加上使用 TypeScript 會是更好的選擇。

糟糕的：

function combine(val1, val2) {
  if (
    (typeof val1 === 'number' && typeof val2 === 'number') ||
    (typeof val1 === 'string' && typeof val2 === 'string')
  ) {
    return val1 + val2;
  }

  throw new Error('Must be of type String or Number');
}

適當的：

function combine(val1, val2) {
  return val1 + val2;
}

用ＴＳ或者寫測試吧？

---

#### 別過度優化
現代瀏覽器在運行時幫你做了很多優化。大多數的情況，你所做的優化都是在浪費你的時間。這裏有些很好的資源，去了解哪些優化是無用的。
糟糕的：

// 在舊的瀏覽器中並不會快取（cache）`list.length`，每次迭代（iteration）時的重新計算相當損耗效能。
// 這在新瀏覽器中已被優化，你不用手動去快取。
for (let i = 0, len = list.length; i < len; i++) {
  // ...
}

適當的：

for (let i = 0; i < list.length; i++) {
  // ...
}

#### 移除無用的程式碼（Dead Code）
糟糕的：

function oldRequestModule(url) {
  // ...
}

function newRequestModule(url) {
  // ...
}
const req = newRequestModule;
inventoryTracker('apples', req, 'www.inventory-awesome.io');

適當的：

function newRequestModule(url) {
  // ...
}
const req = newRequestModule;
inventoryTracker('apples', req, 'www.inventory-awesome.io');

可以用git來控管？

### 小結
1. 命名好function 名稱
2. 一個function盡量只做一件事情（可讀性)

---