0

先懺悔一下好了。前篇討論 LINQ 邏輯執行時機的文章不小心示範了「好寫好用但不該推廣的技巧，」但未加註「叔叔有練過，小朋友不要學」或「叔叔在寫 Side Project，不會害到人」警語，恐有誤導之嫌。撰文前其實曾閃過「是否不妥」的念頭，但想想覺得還好便沒放心上。貼文後讀者 Shu Huan Huang 提醒，我意識到確實可能做了不良示範誤導新同學，故補上這篇平衡一下。

許多程式人員會抱著「程式能動就好」的心態寫程式，不在意執行效能、是否有資安漏洞、程式碼是否好理解易修改能擴充，並把「不管黑貓白貓，能抓耗子的就是好貓」常掛嘴上強調正當性。

貓能抓耗子可以解決問題沒錯。但如果這隻會抓耗子的貓：

  • 只吃進口米其林級貓罐頭
  • 每天四處拉屎撒尿抓爛家俱又滿身跳蚤
  • 搬家換個新環境就忘記怎麼抓老鼠
  • 三天兩頭去獸醫院報到

這樣，還能算是一隻好貓嗎？

同樣的，如果某支能動的程式：

  • 只有原作者知道怎麼修改，其他人一碰就壞
  • 程式一天到晚被抓到漏洞，SQL Injection、XSS 樣樣都來
  • 需求稍改就沒法用了，要調整擴充又不知從何下手
  • 系統三天兩頭出錯，救火救到龜藍波火

這樣的程式很難說是好程式吧？

寫了三十多年程式，經過 N 個十萬小時的焠鍊，我寫過不少元件、程式庫及框架，通過多年商業運轉及持續擴充的考驗，我對自己程式碼的簡潔性、安全性、可擴充性還挺有信心，但對可讀性的體會相對較淺，在閒聊 - 「好程式」跟你想的不一樣! 初讀「重構」有感一文提過我曾深受震憾，對可讀性有了全新認識!

當今軟體開發的主流思維，程式可讀性的優先性應排在簡潔、效率之前，理由是低可讀性程式的維護成本常超乎想像，一味講求潔簡、效能，固然能少寫幾行程式少跑幾個指令節省幾個 CPU 時序，代價卻是程式不易理解、難以修改擴充，得不償失。 而當程式碼本身能明確表達意圖，不需要註解、文件或追進程式碼就能理解程式碼的目的，自然能提供良好的可讀性。重構技巧便很注重類別、變數、函式的命名，力求清楚表達意圖減少誤解，讓程式碼好懂易讀。

任何一個傻瓜都能寫出電腦可以理解的程式(能抓耗子的貓)，唯有優秀的程式設計師能寫出讓人讀懂的程式(好貓)。 by M. Fowler (1999)

在前篇文章我提到兩個取巧寫法：

  1. 用 jQuery.map() 取代 jQury.each() 跑迴圈，callback 函式可由 function(idx, element) 簡寫成 function(element)
  2. 借用 Select(o => ...).Count() 進行每一筆資料有效性檢查，比 ToList().ForEach() 或 foreach () 少打幾個字元

這兩個取巧寫法執行結果都正確，估計不會有效能或安全性問題，我也曾在不少別人的程式碼看過，但它們稱不上良好的做法，容易混淆程式碼意圖導致後人誤解改錯，不值得鼓勵。這些在實務上常見，乍看有益卻存在瑕疵(可能是效能、安全或可讀性)終致得不償失的程式寫法或系統設計，有個專有名詞叫 Anti-Pattern (反面模式)。

回頭來看上述兩個取巧做法錯在哪裡？問題出在會混淆意圖降低可讀性!

jQuery 對 each() / map() 賦與了不同意義，map() 預期該傳回轉換後的陣列，即便它容許 callback 什麼都不回傳，完全不用變數接收傳回陣列依能完美執行不出錯，但借用 MDN 文件關於「什麼時候不要用 map()」的說明：

因為 map 會建立新的陣列，如果在不想建立新陣列時使用該方法，就會變成反模式（anti-pattern）：這種情況下，要使用 forEach 或 for-of。 以下情況不應該使用 map；

  1. 不使用回傳的新陣列，
  2. 或/且不需要回傳新陣列。

而用 Select() 取代 ForEach() 觸犯的問題也相似。

當 「Select()/.map() 是用來傳回新陣列」是程式開發人員的普遍認知，借作其他用途易超出其他人的預期而一頭霧水。我自己有個拿捏底線 - 不該在 Select()/map() 更動來源陣列。若會修改來源就會回歸 ForEach()/each()，理由是後人追查邏輯時通常不會優先檢查 Select()/map() 內部，等踏破鐵鞋才發現它被藏在不該出現的地方，肯定奉上成串花惹發，這麼做是不折不扣的挖坑給人跳呀! 與借用 Select()/map() 跑唯讀迴圈需多花點腦筋理解，損陰德程度有別。

開發人員遵守戒律的程度不同，從早晚禮佛、堅持不沾葷腥、吃方便素，一直到允許酒肉穿腸過，信仰深度有別，各有自己的尺度。我肯定不是嚴格奉行紀律的那一型，常覺得 Coding 該像藝術創作，搞到像工程營造樂趣全失，但回歸企業應用系統及團隊開發，一致的 Coding Style 與程式碼可讀性是提升品質降低成本的基本要求，依我的觀點，有些取巧可被忍受，有些偷懶天地難容，我的拿捏尺度介於二者之間，所以文章偶爾會出現為求省事簡潔的取巧寫法，某些已接近 Anti-Pattern，理應加上警語。

前文案案用 Select() 取代 ForEach() 跑迴圈檢核我認為還行(雖然不符正統規範)，若在其中更動陣列內容就不 OK 了，必須改用 ForEach() 或 foreach 以免害人。不過在文章裡遺漏說明這點原則，擔心有些人舉一反三發揚發光大，把 Select() 完全當 ForEach() 用大搞更新修改，屆時引發災難可就不妙了，故特別再寫一篇補充說明。

最後，我試著用最小幅度修改讓它更好讀一些，改用夠精簡且意圖更吻合的 LINQ 方法 - All()，寫成：


static IPAddress ParseIp(string ip)
{
    Console.WriteLine($"[DEBUG] Check {ip}");
    IPAddress r;
    if (IPAddress.TryParse(ip, out r)) return r;
    throw new ApplicationException(
        $"{ip} 不是有效 IP 地址");
}
static bool CheckIp(string ip) 
{
    ParseIp(ip);
    return true;
}    
static void Main(string[] args)
{
    var rawData = new Dictionary<string, string>()
    {
        ["IP1"] = "127.0.0.1",
        ["IP2"] = "::1",
        ["BAD"] = "喂! 我不是 IP 啦"
    };
    try
    {
        rawData.Values.All(o => CheckIp(o));
        Console.WriteLine("資料有效");
    }
    catch (Exception ex)
    {
        Console.WriteLine($"資料無效 - {ex.Message}");
    }
    Console.ReadLine();
}

Some thoughts about frequently used coding style which are handy, concise but not always good.


Comments

Be the first to post a comment

Post a comment