台部落侯文成

建議133：用camelCasing命名私有字段和局部變量私有變量和局部變量只對本類型負責，它們在命名方式也採用和開放的屬性及字段不同的方法。camelCasing很適合這類命名。 camelCasing和PascalCasing

2020-02-23 11:12:17

建議134：有條件地使用前綴在.NET的設計規範中，不建議使用前綴。但是，即便是微軟自己依然廣泛的使用這前綴。最典型的前綴是m_，這種命名一方面是考慮到歷史沿革中的習慣問題，另一方面也許我們確實有必要這麼做。在一個不是很龐

2020-02-23 11:12:17

建議132：考慮用類名作爲屬性名一般來說，若果屬性對應一個類型，應該直接用類型名命名屬性名。如下： class Person { public Company Company { get; set

2020-02-23 11:12:17

建議130：以複數命名枚舉類型，以單數命名枚舉元素枚舉類型應該具有負數形式，它表達的是將一組相關元素組合起來的語義。比如： enum Week { Monday, Tuesday,

2020-02-23 11:12:17

建議135：考慮使用肯定性的短語命名布爾屬性布爾值無非就是True和False，所以應該用肯定性的短語來表示它，例如，以Is、Can、Has作爲前綴。布爾屬性正確命名的一個示例如下： class SampleCla

2020-02-23 11:12:17

建議152：最少，甚至是不要註釋以往，我們在代碼中不寫上幾行註釋，就會被認爲是鐘不負責任的態度。現在，這種觀點正在改變。試想，如果我們所有的命名全部採用有意義的單詞或詞組，註釋還有多少存在的價值。即便再詳細的註釋也不能優化糟糕的

2018-09-02 09:28:33

建議153：若拋出異常，則必須要註釋有一種必須加註釋的場景，即使異常。如果API拋出異常，則必須給出註釋。調用者必須通過註釋才能知道如何處理那些專有的異常。通常，即便良好的命名也不可能告訴我們方法會拋出那些異常，在這種情況下，使用註

2018-09-02 09:28:33

建議154：不要過度設計，在敏捷中體會重構的樂趣有時候，我們不得不隨時更改軟件的設計：如果項目是針對某個大型機構的，不同級別的軟件使用者，會提出不同的需求，或者隨着關鍵崗位人員的更替，需求也會隨個人意志有所變更。如果競爭對手增加了

2018-09-02 09:28:33

建議157：從寫第一個界面開始，就進行自動化測試如果說單元測試是白盒測試，那麼自動化測試就是黑盒測試。黑盒測試要求捕捉界面上的控件句柄，並對其進行編碼，以達到模擬人工操作的目的。具體的自動化測試請學習Code UI Autom

2018-09-02 09:28:33

建議155：隨生產代碼一起提交單元測試代碼首先提出一個問題：我們害怕修改代碼嗎？是否曾經無數次面對亂糟糟的代碼，下決心進行重構，然後在一個月後的某個週一，卻收到來自測試版的報告：新的版本，沒有之前的版本穩定，性能也更差了，Bug似乎

2018-09-02 09:28:32

建議147：重構多個相關屬性爲一個類若存在多個相關屬性，就應該考慮是否將其重構爲一個類。查看如下類： class Person { public string Address { get; set

2018-09-02 09:28:32

建議149：使用表驅動法避免過長的if和switch分支隨着代碼變得複雜，我們很容易被過長的if和switch分支困擾。一個類枚舉類型Week如下： enum Week { Monday,

2018-09-02 09:28:32

建議142：總是提供有意義的命名除非有特殊原型，否則永遠不要爲自己的代碼提供無意義的命名。害怕需要過長的命名才能提供足夠的意義？不要怕，其實我們更介意的是在代碼的時候出現一個iTemp。 int i 這樣的命名只能出現在循環

2018-09-02 09:28:32

建議150：使用匿名方法、Lambda表達式代替方法方法體如果過小（如小於3行），專門爲此定義一個方法就會顯得過於繁瑣。比如： static void SampeMethod() {

2018-09-02 09:28:32

建議138：事件和委託變量使用動詞或形容詞短語命名事件和委託使用場景是調用某個方法，只不過這個方法由調用者賦值。這決定了對應的變量應該以動詞或形容詞短語命名。關於事件和委託變量妥當的命名示例如下： publi

2018-09-02 09:28:32