給自己佈置這個標體在這裡的時候, 我就知道不是一個好的題目. 並且這個也是一個持續的體會和總結.

當然, 對於一個好的程式碼的評判, 網上搜索可能一大推. 在多年coding後, 總結出來也會差不多.

基本上大方向的:

1. 可讀性
2. 可維護性
3. 可擴充套件性

從實際角度考慮的:

1. 邏輯清晰
2. 執行效率高
3. 問題(bug)少

進一步的:

1. 演算法上有調優處理 -- 可能歸結為效率問題
2. 有模式上的實現 -- 認為 模式是對邏輯清晰的一種命名, 將這個事情進行固化
3. 模組之間的解耦 -- 多人開發,溝通協作上有利, 也利於編碼的可讀性

所以, 理解一下, 程式碼好壞與否, 在於兩大塊:

1. 程式碼的溝通上
   
   程式碼作為程式的實現, 更作為程式設計師之間的語言, 是大家的一個工作"溝通"之地, 高效溝通是基礎
2. 程式碼的實際執行上
   show me the code, 程式碼的高效產出結果才是目的

所以, 到這裡我還沒有達到我表體要說的事情, 具體這些還是原則上的東西. 所以, 有沒有一些具體的東西呢?

我自己簡單想了一下, 也爭取做一個持續的總結整理, 這裡只說一些具體的程式碼書寫習慣以及風格上的東西

多條件判斷場景

上程式碼, 經常遇到很多個條件下的判斷的問題, 存在多個符合條件下的判斷

function whatYouWillSay(role) {

    const conditionA = ...;
    const conditionB = ...;
    const conditionC = ...;

    if (conditionA && conditionB && conditionC) {
        ...
    }

}
 

我的一個感覺就是非常不清晰, 別人讀取這些條件判斷的時候很不容易理解
我的一個感覺比好的體驗是: 如果過分複雜,(將判斷條件單獨提出這個再說)

需要提取一些短路判斷, 比如上邊的判斷

function ...(){
    if (!conditionA){
        return ...
    }

    if (!condtionB) {
        return ...
    }

    if (!condtionC) {
        return ...
    }

    //到這裡的條件肯定都是滿足的了, 上邊的判斷儘量簡單明瞭, 讓大家知道是什麼意思
    //並且方法命名上也能自解釋
    return ...

}
 

要有預設值的返回

對於一個方法, 首先要有一個判定, 我的輸入和輸出是什麼, 然後再進行具體實現. 對於輸出最好有一個預設值
所以 typescript 這裡做得就比較好, 如果有宣告輸出, 沒有顯示輸出的話, 經常會提示錯誤

function returnStr() : string {

    ...


    // 我是一個 str
    return 'defaultStr'
}

寫法上儘量少的建立一些中間變數

但是如果中間變數可以讓程式碼更清晰的話, 那就建立吧. 這裡想到一個例子, 比如對陣列需要做一個統計返回的處理
reducer 都可以進行實現.

例如最普通的求和

const arr = [];
const sum = arr.reduce((sum, cur)=>sum+cur, 0);

例如要去遍歷一個數組, 但是需要根據陣列輸出一個東西 (其實類似上邊的求和, 複雜了一些)

const arr = [4,5,6];

const effectYourSomething = arr.reduce((effect, item, index)=>{
    effect[item] = index
    return effect;;
}, {})

//輸出
{4: 0, 5: 1, 6: 2}

總結

一種習慣或者素養, 並且是一個不斷持續的過程.