【轉】編寫高質量代碼改善C#程序的157個建議——建議142:總是提供有意義的命名
阿新 • • 發佈:2017-12-11
int 每一個 改善 public static col turn nds item
建議142:總是提供有意義的命名
除非有特殊原型,否則永遠不要為自己的代碼提供無意義的命名。
害怕需要過長的命名才能提供足夠的意義?不要怕,其實我們更介意的是在代碼的時候出現一個iTemp。
int i 這樣的命名只能出現在循環中(如for循環),除此之外,我們找不到任何理由在代碼的其他地方出現這樣的無意義命名。
例如,以下命名都是良好的典範:
private CultureInfo m_CurrentCulture; private CultureInfo m_CurrentUICulture; private int m_ManagedThreadId;private string m_Name; private int m_Priority; public static int GetDomainID() { return GetDomain().GetId(); } public override int GetHashCode() { return this.m_ManagedThreadId; } private extern bool JoinInternal(intmillisecondsTimeout);
我們可以看到每一個命名都表達了本身具有的含義。良好的命名帶來的一個顯而易見好處是,我們甚至可以減少大部分的代碼註釋。
糟糕的命名如下:
int theID; int GetID(int a, int b) { int iTemp; //省略 return iTemp; }
這個反例,字段變量theID指示不明,閱讀者看到這樣的命名根本不知道開發者所表達的意思。方法GetID的參數a和b也是指示不明的,調用者根本不知道應該傳入什麽值。內部的ITemp同樣糟糕,時間一長,即便開發者本人也會忘記當初所設定的這個變量的含義。
轉自:《編寫高質量代碼改善C#程序的157個建議》陸敏技
【轉】編寫高質量代碼改善C#程序的157個建議——建議142:總是提供有意義的命名