閱讀 IDE 給的提示

現代的 IDE 很方便，當工程師編輯代碼時，IDE 會即時檢查代碼，並根據一些預設的規則，提示哪部分的代碼可能需要調整。不同的語言，不同的 IDE 提示狀況都不太一樣，但是或多或少都會有這個功能，提醒工程師可能要注意某段代碼是否有問題。

#到處都是的提示和警告

如果代碼總是穿插著不同顏色的提示，可能會讓工程師不想去處理這群成堆的提示，也不在乎自己寫的代碼是否多了一條提示，形成破窗效應。每種提示和警告都有不同的意義，有些是提醒拼錯字，有些是提示代碼存在 Side Effect。如果放任這些提示與警告蔓延在代碼中，除了會讓代碼品質日益下降，甚至會讓工程師忽略掉真正潛在的危險。

#提示與警告的功用

1. 提示不符合規則的寫法
   • 拼字錯誤：當變數名稱對不上某個英文單字時，IDE 就會提示你可能拼錯字。但是當單字是領域特有單字時，為了避免這種不必要的提示，就需要把這個單字加到 IDE 的預設字典中，讓提示可以認得這個單字。
   • 語言的命名規則，例如：以方法名稱為例，C# 預設方法名稱命名規則是開頭大寫的大駝峰命名法，而 Java 則是開頭小寫的小駝峰式命名法。當不符合這些規則時，IDE 就會提示你需要修改它。
2. 更好的做法的提示
   • 除了檢查拼字或命名規則，有些 IDE 還會建議更好的做法，例如：在 Rider 中，如果寫了下面這段代碼，一段由 for 處理的邏輯
     dart

     var duplicateCount = 0;
     foreach (var entry in cnt)
     {
         if (entry.Value > 1) duplicateCount++;
     }
     
     return duplicateCount;

     Rider 就會在 foreach 的部分提示使用 LINQ 改寫

     c#

     cnt.Count(entry => entry.Value > 1);

     大多時候仔細閱讀這類型的提示，可以了解到什麼是更好的做法。尤其當自己是初學者的時候，這些提示都能幫助自己更好的了解這個語言的一些特性。

3. 潛在的風險的警告
   • 有些時候，工程師可能寫出一寫有 Side Effect 的代碼，寫的時候沒有，以下面這段 C# 代碼為例，IDE 就提示了 gameResults 有重複執行多次的可能性，如果今天傳入這個方法的參數不是 List，而是 LINQ，就會導致 gameResults 跑了兩次迴圈，計算的卻是相同的東西。

   

#團隊特有的規則

這些提示都是根據每個語言的預設規則提示的，只要代碼不符合規則，IDE就會在代碼下方標註。但是有一種情況是開發團隊有自己一套規則，以 C# 為例，有些團隊習慣宣告變數時使用確定型別，讓閱讀代碼的人可以清楚知道這個變數是什麼型別。但是 IDE 會提示使用 var，因為 C# 能夠透過型別論來推斷變數型別，所以預設規則傾向於用更簡潔的寫法。

Customer customer = customerApi.Get(id);

在這種情況，就會產生團隊規則與 IDE 規則不同，導致代碼上出現不必要的提示。這時我們不應該放任警告與提示的存在畫面上，而是應該去調整自己的 IDE 設定，讓 IDE 不要因為這些命名規則持續地跳出警告。

#小結

保持代碼沒有任何提示與警告，沒有無謂的波浪線與虛線，能讓閱讀代碼時能更專注，也能在真正需要的時候，讓 IDE 來提示你。除此之外，團隊的規則應該凌駕於所有寫法之上，畢竟代碼是團隊的，共同的寫法更是團隊協作的基礎，基本上除了可能造成 Side Effect 的提示之外，剩下的寫法優先度應該是以團隊共識為優先。

#題外話

這篇原本是在鐵人賽的時候寫的，那是我第一次比較有系統地寫文章，也寫的比較倉促，所而有些凌亂。發在 Medium 的這篇則是整理一下原文，調整架構，並加上更多解釋。未來其他我覺得比較有意義文章整理到 Medium 這邊。