寫出優雅簡明代碼的論題集 — Csharp(C#)篇[2]

文章目錄

• 論題七：命名規範
• 論題八: 一個方法的參數不能超過5個，當多於5個時，應進行函數的拆分或者參數的封裝。-- 謔謔就像論題一樣的規定
• 論題九： 不要濫用注釋，有些非常清晰明確的代碼不需要注釋
• 論題十： 不要把數值hard-code在代碼中，使用const 來定義
• 論題十一： 不要使用””, 使用string.Empty
• 論題十二： 善於合并if

謝謝大家對本系列第一篇寫出優雅簡明代碼的論題集 -- Csharp(C#)篇[1]的回複和討論，我相信針鋒相對的辯論不僅有助於發現答案，更讓我們瞭解問題後面的實質。

對程式員而言，我們的代碼需要：

1. 在預算內實現需求，讓使用者可以使用 -- 讓自己或者公司可以賺到錢

2. 方便自己修改及日後維護

3. 方便別人修改及日後維護

4. 便於重複使用，為以後的開發節省時間

5. 讓系統高效的運作

從美國商學院畢業的學生們掌握了很多相似的思維模式，這不僅有利於他們解決問題，更重要的是方便他們彼此之間溝通。-- 換句話說，他們畢業後都安裝上了相同的協議和一些可通用的介面，這樣有一個基礎平台可以讓他們協同工作。

論題七：命名規範

也許有人認為沒有必要再提這個問題，但在日常編碼生活中，這的確是一個很重要的話題。

7.1  類名、方法、常數使用Pascal casing

 public class MyClass{    const int DefaultNumber = 100;    public void MyMethod()    { }}

7.2 局部變數，參數用camel casing

 

             partial void OnContactIdChanging(int value)            {                int number;            }

  

7.3 interface 名字以I 開頭

7.4 盡量不用單個字元命名變數，象 i 或者 t 。使用 index 或者 temp 之類代替。

7.5 將所有來自framework 的 namespace 放在前面，而後再放第三方或自訂的: 

 using System;using System.Linq;using System.Data.Linq;using System.Collections.Generic;using System.Text;using System.ComponentModel.DataAnnotations;using CodeSmith.Data.Attributes;using CodeSmith.Data.Rules;

 

論題八: 一個方法的參數不能超過5個，當多於5個時，應進行函數的拆分或者參數的封裝。-- 謔謔就像論題一樣的規定

一些說明：不是為了給自己一個緊箍咒，而是在日常編程中，我們發現如果你寫的方法不滿足這樣一個條件，一年後，就算是你自己也不太想去維護和修改，如果換成是其他程式員會對此更加的頭痛，對嗎？

論題九： 不要濫用注釋，有些非常清晰明確的代碼不需要注釋

僅在必要的時候注釋你的代碼，不要太多，並且注釋也要簡單給力。

論題十： 不要把數值hard-code在代碼中，使用const 來定義論題十一： 不要使用””, 使用string.Empty

正確的：

 string name = string.Empty;

不建議：

 string name = "";

論題十二： 善於合并if

觀察下面這段可愛的代碼：

View Code

public bool Equals(CommentData obj) {
if (!CommentId.Equals(obj.CommentId)) return false;
if (!Comment.Equals(obj.Comment)) return false;
if (!CommentorId.Equals(obj.CommentorId)) return false;
return true;
    }

如果我們寫成這樣會不會好些呢：

View Code

public bool Equals(CommentData obj) {
return CommentId == obj.CommentId &&
             Comment.Equals(obj.Comment) &&
             CommentorId == obj.CommentorId;
    }

觀察下面這段可愛的代碼：

 

 public bool Equals(CommentData obj) {      if (!CommentId.Equals(obj.CommentId)) return false;      if (!Comment.Equals(obj.Comment)) return false;      if (!CommentorId.Equals(obj.CommentorId)) return false;      return true;    }

如果我們寫成這樣會不會好些呢：

 public bool Equals(CommentData obj) {      return CommentId == obj.CommentId &&             Comment.Equals(obj.Comment) &&             CommentorId == obj.CommentorId;    }

 論題十三： 不斷重構你的代碼

當有新的需求或新改動的時候，可以撥一些時間來重構。 -- 你可能突然發現，原來重構後的代碼可以如此美麗。使用一些重構的外掛程式，比如resharper可以使你事半功倍。

 當有新的需求或新改動的時候，可以撥一些時間來重構。 -- 你可能突然發現，原來重構後的代碼可以如此美麗。使用一些重構的外掛程式，比如resharper可以使你事半功倍。

未完待繼…

相關閱讀：

寫出優雅簡明代碼的論題集 -- Csharp(C#)篇[1]