跳至內容

C# 程式設計/命名

來自華夏公益教科書,自由的教學內容

本節將定義 C# 開發社群普遍接受的命名約定。一些公司可能會定義與之不同的命名約定,但這在個別情況下進行,通常不鼓勵。本節中討論的一些物件可能超出了讀者目前的知識範圍,但可以以後再參考本節。

許多命名標準源自微軟的 .NET 框架庫。這些標準已被證明可以使名稱易於閱讀和理解。“一目瞭然”。透過在命名物件時使用正確的約定,您可以確保其他閱讀您程式碼的 C# 程式設計師能夠輕鬆理解這些物件,而無需搜尋程式碼以查詢其定義。

名稱空間

[編輯 | 編輯原始碼]

名稱空間使用帕斯卡命名法(也稱為UpperCamelCase)命名,不帶下劃線。這意味著名稱中每個單詞的第一個字母都大寫。例如:MyNewNamespace。帕斯卡命名法還意味著三個或更多個字母的縮略詞只應首字母大寫(MyXmlNamespace 而不是 MyXMLNamespace)。

程式集

[編輯 | 編輯原始碼]

如果程式集只包含一個名稱空間,則程式集和名稱空間應使用相同的名稱。否則,程式集應遵循正常的帕斯卡命名法格式。

類和結構

[編輯 | 編輯原始碼]

帕斯卡命名法,不帶下劃線或前導Ccls,或I。類不應與它們所在的名稱空間同名。任何三個或更多個字母的縮略詞都應使用帕斯卡命名法,而不是全部大寫。儘量避免縮寫,並儘量始終使用名詞。

異常類

[編輯 | 編輯原始碼]

遵循類命名約定,但在名稱末尾新增 Exception。在 .Net 2.0 中,所有類都應從System.Exception基類繼承,而不是從System.ApplicationException繼承。

遵循類命名約定,但以I開頭,並將I之後的字母大寫。例如:IFooI字首有助於區分介面和類,並避免名稱衝突。

帕斯卡命名法,不帶下劃線,事件處理程式除外。儘量避免縮寫。許多程式設計師有過度縮寫一切的壞習慣。應該避免這種情況。

屬性和公共成員變數

[編輯 | 編輯原始碼]

帕斯卡命名法,不帶下劃線。儘量避免縮寫。

引數和過程級變數

[編輯 | 編輯原始碼]

駱駝命名法(或lowerCamelCase)。儘量避免縮寫。駱駝命名法與帕斯卡命名法相同,但第一個單詞的第一個字母小寫。

類級私有和保護變數

[編輯 | 編輯原始碼]

駱駝命名法,以下劃線開頭。始終在宣告中表明protectedprivate。以下劃線開頭是本文件中唯一有爭議的地方。前導字元有助於防止在建構函式中發生名稱衝突(引數和私有變數具有相同的名稱)。

窗體上的控制元件

[編輯 | 編輯原始碼]

帕斯卡命名法,以標識它屬於 UI 而不是純粹的編碼控制元件(例如一個臨時變數)的字首。許多開發人員使用ui作為字首,後跟描述性名稱,例如txtUserNamelblUserNickName(“txt”代表 TextBox 控制元件,“lbl”代表 Label 控制元件)

這實際上是駱駝命名法;此外,這種命名約定被稱為匈牙利命名約定,在現代程式設計中通常不鼓勵。這種風格的變數具有類似 lblSurname 或 tbSurname 的名稱,而不是 surnameLabel 或 surnameTextBox。這也有額外的好處,即類似的 UI 元素在 IntelliSense 中按字母順序連續排列。

下面是一些針對 ASP.Net 網頁表單控制元件的示例

控制元件 字首 示例
標籤 lbl lblSurname
文字框(ASP.Net) tb tbSurname
文字框(WinForms) txt txtUserName
資料網格 dg dgResults
網格檢視 gv gvResults2
按鈕 btn btnSave
影像按鈕 iBtn iBtnSave
超連結 lnk lnkHomePage
組合框 cmb cmbYear
下拉列表 ddl ddlCompany
列表框 lst lstCompany
資料列表 dLst dLstAddress
資料集 ds dsInvoices
資料表 dt dtClients
資料行 dr drUser
中繼器 rep repSection
複選框 chk chkMailList
複選框列表 chk chkAddress
單選按鈕 rBtn rBtnGender
單選按鈕列表 rBtn rBtnAgeGroup
影像 img imgLogo
面板 pnl pnlSevtion
PlaceHolder plh plhHeader
日曆 cal calMyDate
廣告輪播器 adr adrBanner
表格 tbl tblResults
所有驗證器 val (N/A) valCreditCardNumber
驗證摘要 vals (N/A) valsErrors

帕斯卡命名法。不建議使用 SCREAMING_CAPS。這與早期的約定有很大不同。大多數開發人員現在意識到,使用 SCREAMING_CAPS 會暴露比必要更多的實現細節。大部分的 .NET Framework 設計指南 都專門討論了這個問題。

以下是一個使用所有這些命名約定的類的示例。

using System;

namespace MyExampleNamespace
{
    public class Customer : IDisposable
    {
        private string _customerName;
        public string CustomerName 
        { 
            get 
            { 
                return _customerName; 
            }
            set
            {
                _customerName = value;
                _lastUpdated = DateTime.Now;
            }
        }

        private DateTime _lastUpdated;

        public DateTime LastUpdated
        {
            get
            {
                return _lastUpdated;
            }
            private set
            {
                _lastUpdated = value;
            }
        }

        public void UpdateCustomer(string newName)
        {
            if (!newName.Equals(CustomerName))
            {
                CustomerName = newName;
            }
        }

        public void Dispose()
        {
            //Do nothing
        }
    }
}


華夏公益教科書