編寫更好的C#代碼

2019-11-17 02:18:24

字體：大中小

來源：轉載

供稿：網友

編寫更好的C#代碼

引言

　　開發人員總是喜歡就編碼規范進行爭論，但更重要的是如何能夠在項目中自始至終地遵循編碼規范，以保證項目代碼的一致性。并且團隊中的所有人都需要明確編碼規范所起到的作用。在這篇文章中，我會介紹一些在我多年的從業過程中所學習和總結的一些較好的實踐。

　舉例為先

　　我們先來看一個 FizzBuzz 示例。FizzBuzz 要求編寫一個程序，遍歷從 1 到 100 的數字。其中如果某數字是 3 的倍數，則程序輸出 “Fizz”。如果某數字是 5 的倍數，則輸出 “Buzz”。如果某數字即是 3 的倍數也是 5 的倍數，則輸出 “FizzBuzz”。如果數字既不是 3 的倍數也不是 5 的倍數，則只需輸出該數字本身。

　　示例1：

12345678910111213141516171819202122 public static void Test(){for (int i = 1; i < 101; i++){if (i % 3 == 0 && i % 5 == 0){Console.WriteLine("FizzBuzz");}else if (i % 3 == 0){Console.WriteLine("Fizz");}else if (i % 5 == 0){Console.WriteLine("Buzz");}else{Console.WriteLine(i);}}}

　　什么感覺？這段代碼需要改進嗎？

　　示例2：

1234567891011 public static void Check(){for (int i = 1; i <= 100; i++){string output = "";if (i % 3 == 0) { output = "Fizz"; }if (i % 5 == 0) { output = output + "Buzz"; }if (output == "") { output = i.ToString(); }Console.WriteLine(output);}}

　　現在感覺如何？還能不能進一步改進？

　　好，讓我們來嘗試改進下。代碼命名對所有軟件開發人員來說都是件非常困難的事情。我們花費了大量的時間來做這件事，而且有太多的需要被命名的元素，例如屬性、方法、類、文件、項目等。不過我們的確需要花費一些精力在這些命名上，以使代碼中的名稱更有意義，進而可以提高代碼的可讀性。

1234567891011121314151617181920212223242526 public void DoFizzBuzz(){for (int number = 1; number <= 100; number++){var output = GetFizzBuzzOutput(number);Console.WriteLine(output);}}PRivate static string GetFizzBuzzOutput(int number){string output = string.Empty;if (number % 3 == 0){output = "Fizz";}if (number % 5 == 0){output += "Buzz";}if (string.IsNullOrEmpty(output)){output = number.ToString();}return output;}

　　這次感覺怎樣？是不是比之前的示例要好些？是不是可讀性更好些？

　什么是更好的代碼？

　　首先就是代碼要為人來編寫，其次是為機器。從長期來看，編寫可讀性好的代碼不會比編寫混亂的代碼要花費更長的時間。如果你能夠非常容易地讀懂你寫的代碼，那么想確認其可以正常工作就更容易了。這應該已經是編寫易讀代碼足夠充分的理由了。在很多情況下都需要閱讀代碼，例如在代碼評審中會閱讀你寫的代碼，在你或者其他人修復Bug時會閱讀你寫的代碼，在代碼需要修改時也會讀到。還有就是當其他人準備在類似的項目或有類似功能的項目中嘗試復用你的部分代碼時也會先閱讀你的代碼。

　　“如果你只為你自己寫代碼，為什么要使代碼更具可讀性？”

　　好，編寫易讀的代碼最主要的原因是，在未來的一到兩周，你將工作在另一個項目上。而此時，有其他人需要修復當前項目的一個Bug，那么將會發生什么？我敢保證他肯定會迷失在你自己編寫的恐怖代碼中。