TA貢獻1816條經(jīng)驗 獲得超6個贊
根據(jù)StyleCop規(guī)則文檔，順序如下。
在類，結構或接口中：（SA1201和SA1203）
常數(shù)場
領域
建設者
終結器（析構函數(shù)）
代表們
大事記
枚舉
接口（接口實現(xiàn)）
性質(zhì)
索引器
方法
結構
班級
在以下每個組中，按訪問順序排序：（SA1202）
上市
內(nèi)部
受保護的內(nèi)部
受保護的
私人的
在每個訪問組中，先按靜態(tài)，然后按非靜態(tài)順序排序：（SA1204）
靜態(tài)的
非靜態(tài)
在每個靜態(tài)/非靜態(tài)字段組中，按只讀順序排序，然后按非只讀順序排序：（SA1214和SA1215）
只讀
非只讀
展開的列表長130行，因此在這里我不會展開。展開的方法部分是：
公共靜態(tài)方法
公開方法
內(nèi)部靜態(tài)方法
內(nèi)部方法
受保護的內(nèi)部靜態(tài)方法
受保護的內(nèi)部方法
受保護的靜態(tài)方法
受保護的方法
私有靜態(tài)方法
私人方法
文檔指出，如果規(guī)定的順序不合適（例如，正在實現(xiàn)多個接口，并且應該將接口方法和屬性分組在一起），則可以使用局部類將相關的方法和屬性分組在一起。
TA貢獻1841條經(jīng)驗 獲得超3個贊
這是一個古老但仍然非常相關的問題，因此，我將添加以下內(nèi)容：打開以前可能已經(jīng)讀過或未曾閱讀過的類文件時，尋找的第一件事是什么？田野？屬性？我從經(jīng)驗中意識到，幾乎總是要去尋找構造函數(shù)，因為最基本的要了解的是如何構造該對象。
因此，我已經(jīng)開始將構造函數(shù)放在類文件中，并且從心理上來說，結果是非常積極的。將構造函數(shù)放在一堆其他事情之后的標準建議讓人感到不協(xié)調(diào)。
C＃6中即將推出的主要構造函數(shù)功能提供了證據(jù)，證明構造函數(shù)的自然位置位于類的最上層-實際上，甚至在開括號之前也已指定了主要構造函數(shù)。
有趣的是，像這樣的重新排序有多大的不同。它使我想起以前如何對using語句進行排序-首先使用系統(tǒng)名稱空間。Visual Studio的“組織使用”命令使用了此順序。現(xiàn)在，usings僅按字母順序排序，而沒有對System命名空間進行特殊處理。結果感覺更簡單，更干凈。
TA貢獻1998條經(jīng)驗 獲得超6個贊
通常我會嘗試遵循以下模式：
靜態(tài)成員（通常具有其他上下文，必須是線程安全的，等等）
實例成員
每個部分（靜態(tài)和實例）由以下成員類型組成：
運算符（始終是靜態(tài)的）
字段（在構造函數(shù)之前初始化）
構造函數(shù)
析構函數(shù)（是遵循構造函數(shù)的傳統(tǒng)）
屬性
方法
大事記
然后，成員按可見性排序（從不可見到更可見）：
私人的
內(nèi)部
內(nèi)部保護
受保護的
上市
順序不是教條：簡單的類更易于閱讀，但是，更復雜的類需要特定于上下文的分組。
舉報