技術最前線

如何寫出讓人看得懂的原始程式碼

Dino Esposito 你聽說過國際模糊 C 代碼大賽嗎？簡而言之，它是一個開放式的競賽，從少量的 C 程式，解決了一個問題選擇一個贏家 — — 任何問題 — — 用非常模糊和混淆的 C 代碼。你可以找到在前幾年獲獎專案的原始程式碼 ioccc.org/years.html。

經過模糊處理的 c 語言代碼比賽是輕鬆愉快的方式來展示樣式和可讀性程式設計中的重要性。此列將總結一些最重要的做法，你就會真的想要要很容易閱讀和理解的代碼 — — 既對你自己和你的同事。

作為屬性的可讀性

在軟體發展中，可維護性是指易用性，您可以修改現有代碼以實現修復 bug、家政、實施一項新功能或只對一些模式重構的目標屬性。可維護性是軟體的基本屬性之一根據 ISO/IEC 9126 紙。關於軟體的屬性的詳細資訊，請參閱在本文 bit.ly/VCpe9q。

從各種因素，其中之一就是可讀性強的代碼的可維護性結果。很難讀的代碼也是難以理解的。把他們的手放在他們不清楚地知道，理解的代碼的開發人員很容易使代碼變得更糟。

不幸的是，可讀性是非常主觀的問題。開發一個自動的工具來檢查和代碼的可讀性級別的報告是幾乎不可能的。然而，即使自動可讀性測量是可能的任何此類工具可能會被視為非常不可靠和不信任任何人。最後，可讀性是代碼的一個手動的屬性，各個開發人員應檢查和剩下的他們。能夠書寫清晰易讀的代碼應該擴展其技能集的單個開發人員的文化責任的一部分。

一般來說，可讀性是代碼屬性可以並應該學會採取你的程式設計生涯之初的權利和發展和改善隨著時間的推移。就像風格和良好的設計，可讀性不應該留給專家。更重要的是，它不應該推遲到當你只是有足夠的時間了。

可讀性務實的方針

生產可讀的代碼是尊重的一種對其他開發人員。作為一個計算機使用者張貼後，你應該總是代碼好像結束維護你的代碼的人是一個暴力的精神病患者，知道你住在哪裡。您還應考慮的開發人員維護您的代碼，一天，實際上可能你而告終。

當閱讀其他人的代碼，有幾個能讓你抓狂的事情。使它難以閱讀代碼的一個方面是資料結構和演算法與沒有明確的目標。另一個方面是不清楚的策略在代碼中使用，很難確定和通過評論不好 notated。以下為範例：

// Find the smallest number in a list of integers
private int mininList(params int[] numbers)
{
  var min = Int32.MaxValue;
  for (var i = 0; i < numbers.length; i++) {
    int number = numbers[i];
    if (number < min)
      min = number;
  }
  return min;
}

即使我移植的示例在 C# 中為清楚起見，我不得不承認這不是一塊代碼的任何 C# 開發人員想過寫作。原因是與 C# 和 Microsoft.NET 框架中，您可以實現許多相同使用LINQ的結果。我遇到過類似的代碼，在專案中，除了，它用JAVA編寫的。在某種程度上，我被聘為埠對.NET 框架和 C# 代碼。

你可能也遇到代碼那樣真正的.NET 專案中。您可以應用一些可讀性的考慮，而不會丟失你的意圖。在該函數中不工作的第一件事是名稱。公約》是值得商榷的。名稱錯過一個動詞，並使用混合大小寫邏輯。像 GetMinFromList 一樣的東西大概會是一個更好的名稱。然而，代碼的最有爭議點是在名稱中使用的私人限定詞。

該代碼的任何漫不經心的讀者可以看到該函數作為一個實用程式。換句話說，它代表著一塊潛在可重用的代碼，您可以從各種場所內其餘的代碼調用。因此，將它標記為私人並不總是有意義。然而，開發人員知道 YAGNI 規則的力量 — — 你不是要去需要它 — — 和合理，傾向于不公開並不嚴格需要的代碼。

該代碼的作者可能已經預見到函數作為潛在的可重用，但不在寫時。這就是為什麼寫的功能可以方便地變成了一個可重用的 helper 函數，但被標記為私人性質要只在宿主類內可見。這種編碼策略可能很難弄清楚立即為外部讀者。然而，這是只需要幾行的注釋來解釋其動機的決定。如果您不添加適當的注釋，你不是一個好的公民，在編碼的世界。讀者最終弄懂它，而且它會浪費幾分鐘了，更糟的是然而，也能使讀者對作者有點敵意。

可讀性的實用規則

代碼的可讀性是那些其重要性是廣泛認可，但不是一定是正式的學科之一。同時，沒有一些形式化，代碼的可讀性是幾乎空的概念。總體來看，你可以接近可讀性與法治三個 C：評論、一致性和清晰的組合的功能。

IDE 工具是今天比數年前更聰明。開發商有沒有嚴格的需要編寫説明檔和集成他們Visual Studio專案中的自訂文檔。工具提示是無處不在和自動創建的評論。現代的 Ide 中使其很容易定義體制注釋、你所想的只是文本，IDE 將做的休息。體制的注釋是經典的注釋，您將添加到方法和類來提供目標的簡要描述。你應該寫這些評論後平臺或語言的標準。您還應該考慮這些評論任何公開的一段代碼創建為強制性。

禁止明顯的評論是改進的可讀性的道路上另一個基本步驟。明顯的評論只需添加雜訊和不相關的資訊。根據定義，注釋是不是很明顯的代碼中所做的任何決定的任何解釋性文本。注釋應該只是關於代碼的某個特定方面有見地的評論。

第二個"C"是一致性。每個團隊需要使用相同的準則來編寫代碼。如果使用這些指導方針在全公司範圍的基礎上，它就更好。指導方針的時候，很多站在定義什麼準則，停止試圖弄明白什麼是對，什麼是錯。我敢說的對與錯是次要的一點相對於總是做同樣的事情在以同樣的方式在整個代碼中的重要性。

假設您正在編寫一個庫，它不弦操縱。在此庫中的幾個地方，你可能需要檢查字串是否包含給定的子字串。你是怎麼做到的？在.NET Framework 中，JAVASDK，您有至少兩種方式實現相同的結果。您可以使用包含或 IndexOf 方法。不過，這兩個方法，不同的用途。

Contains 方法返回一個布林值的答案，只是告訴你子字串是否包含在一個給定的字串。IndexOf 方法將返回索引基於 0 的搜索的字串所在的位置。如果沒有子字串，IndexOf 返回-1。從純粹功能的角度來看，因此，您可以使用包含和 IndexOf 來達到同樣的目標。

然而，他們給人閱讀的代碼和部隊讀者採取第二次傳遞的代碼，看看是否還有一個特別的原因，而不是包含使用 IndexOf 不同的消息。閱讀行上一次的第二次傳遞當然並不是代碼的一個問題。但當它發生在整個代碼庫的上千行的代碼，並在時間和費用，後來，也有影響。這是不具有高度可讀的代碼的直接成本。

一種代碼應該是責任的一致性的你與生俱來的一部分。作為開發人員，你應該旨在編寫乾淨的代碼第一次不是希望能有足夠的時間來收拾一下了。作為團隊領導，你應執行代碼的一致性準則通過簽入原則。理想情況下，您不應該允許檢查中的任何代碼都不能通過一致性檢驗。

ReSharper 最新版本可使這一想法混凝土相當大的説明。您可以使用這些免費的命令列工具 — — 一整套獨立的工具 — — 將代碼品質分析形式的權利納入你的持續集成（CI）或版本控制系統。這些命令列工具可以執行離線的代碼檢查。這是同一組的代碼檢查，您可以執行在 ReSharper 安裝捕獲代碼中的重複項的Visual Studio內生活。根據你詞的自訂功能，您可能需要裹在特設的元件中的命令列工具。ReSharper 對的詳細資訊，請查閱 bit.ly/1avsZ2R。

第三和最後"C"的代碼就是可讀性的明晰。您的代碼是顯然的如果你的風格它讀起來很好，很容易的方式。這包括相應的分組和嵌套。一般情況下，IF 語句代碼添加大量的噪音。有時你不能避免的條件陳述式 — — 程式設計語言的一個支柱 — — 但試圖限制的 IF 語句的數目保持在控制之下的嵌套和使代碼更易於閱讀。您也可以使用 IF...別的......如果...而不是嵌套的 IF 語句的其他結構。

某些任務可能需要幾行代碼，它可能是硬或採取"提取方法"重構只是並不恰當。在這種情況下，是由空白行分隔的塊中保持這些行好。它並不改變代碼的實質內容，但使它易於閱讀。最後，如果你正在尋找靈感上如何風格您的原始程式碼，看看一些開放原始碼專案。

簡單地說是更好

長線難人類的眼睛看。這就是為什麼報紙和雜誌列印的列中的文本。您的代碼的時候，你應該這樣做，限制線的水準長度和垂直捲動條的方法。方法體的理想長度是什麼？一般來說，30 行應觸發警鈴和建議你考慮重構的最高水準。最後，有良好的組織的專案資料夾和資料夾與命名空間匹配通常反映了各個代碼元素有良好的組織。

當你提高可讀性和乾淨的代碼的主題時，你經常接觸到一種共同反對意見 — — 編寫乾淨的代碼很難，需要大量的時間。你應該試著壓制這一觀點，有兩種方法，你可以。一是使用代碼輔助工具，有助於通過暗示重構、檢查您的代碼好的模式，以及檢查死或重複的代碼編寫乾淨的代碼。如果您可以訪問所有這些功能，你真的有沒有任何藉口不編寫更清潔和可讀的代碼。主要供應商提供的代碼輔助工具。隨便選，但挑選一個。

二是做法的強調自我和你個人的開發人員能夠編寫更簡潔的代碼作為一項一般的態度。有經驗的開發人員，這樣做很好。能夠粗略地知道距離有多遠你是代碼的從您的最後版本，然後真正清理它，是代碼的有經驗的開發人員分開的經驗較少的關鍵特徵。

Dino Esposito 合著的"Microsoft.NET：構建企業應用程式"（微軟出版社，2014年）和"程式設計ASP.NETMVC 5"（微軟出版社，2014年）。.NET 框架和 Android 平臺，它也會經常在世界各地的業內活動中發表演講的技術傳教士，埃斯波西托分享他視覺軟體 software2cents.wordpress.com 和在 Twitter 上 twitter.com/despos。

感謝以下的微軟技術專家對本文的審閱：James McCaffrey