C#编程风格约定
【參考】《.NET設計規范》Krzysztof Cwalina，Brad Abrams著
C#編程世界中存在許多不同的編程風格約定，每一種都有自己的歷史和哲學。本文描述的約定著眼于以下這些目標：
1、必須是實際開發人員使用的約定。為了實現這個目標，我們審查了由.NET框架的開發人員編寫的代碼。有些約定并未在框架中普遍應用，對此我們不予采納。
2、約定應該盡可能的合理、簡潔。我們認為只要不犧牲代碼的可讀性，在更少的行數內編寫更多的代碼通常是有幫助的，因為可以盡可能地減少代碼的分屏和拆行，盡可能地增加代碼的密度（沒有空行）。
3、約定要簡單。我們認為編程約定沒有必要對每一種格式的每一個細節都錙銖必較。過于復雜的約定會難以遵循，而且與一小組核心約定相比，它們不會再增添太多的價值。
一、通用約定風格
1、花括號的使用
- 要把左花括號放在前一條語句的末尾。
if (someExpression){
??? DoSomething();
} - 要使右花括號與左花括號所在的行的行首對齊，除非花括號內只有一條語句。
if (someExpression){
??? DoSomething();
} - 要把右花括號放在新的一行的開始處。
if (someExpression){
??? DoSomething();
} - 考慮把只有一條語句的代碼塊和左右花括號寫在同一行。屬性的訪問方法經常使用這種風格。
public int Foo{
??? get{ return foo; }
??? set{ foo = value; }
} - 考慮把只有一個訪問方法的屬性的所有花括號寫在同一行中。
public int Foo{ get{ return foo; } } - 要使右花括號單獨占一行，除非它后面是else、else if或while。
if (someExpression){
??? do{
??????? DoSomething();
} while(someOtherCondition);
} - 避免省略花括號，即使編程語言允許這樣做。
不應該認為花括號是可以省略的。即使對只有一條語句的代碼塊，仍應該使用花括號。這樣可以增強代碼的可讀性和可維護性。
for (int i=0; i<100; i++){?DoSomething(i); }
只有在極少數情況下才可以省略花括號，比如在原來僅有的一條語句后再添加新的語句是不可能的或是非常罕見的。例如，在throw語句后面再添加任何語句都是沒有意義的：
if (someExpression) throw new ArgumentOutOfRangeException(...);
本條約定的另一個例外是case語句。由于case和break語句已經表示了代碼塊的起始和結束，因此這些花括號可以被省略。
2、空格的使用
- 要在左花括號之后和右花括號之前加一個空格。
public int Foo{ get{ return foo; } } - 避免在左花括號之前加空格。
最好如此：if (someExpression){
可以接受：if (someExpression) { - 要在形式參數之間的逗號后加一個空格。
正確：public void Foo(char bar, int x, int y)
錯誤：public void Foo(char bar,int x,int y) - 避免在實際參數之前加空格。
最好如此：Foo(mychar,0,1)
可以接受：Foo(mychar, 0, 1) - 避免在左圓括號之后或右圓括號之前加空格。
最好如此：Foo(mychar,0,1)
可以接受：Foo( mychar, 0, 1 ) - 不要在成員的名字和左圓括號之間加空格。
正確：Foo()
錯誤：Foo () - 不要在左方括號之后和右方括號之前加空格。
正確：x = dataArray[index];
錯誤：x = dataArray[ index ]; - 不要在控制流語句之前加空格。
正確：while(x==y)
錯誤：while (x==y) - 避免在二元操作符之前和之后加空格。
最好如此：if(x==y){?... }
可以接受：if(x == y){?... } - 不要在一元操作符之前或之后加空格。
正確：if(!y){?... }
錯誤：if(! y){?... }
3、縮進的使用
- 要用4個連續的空格符來進行縮進。
- 不要用制表位（tab）來進行縮進。
- 要對代碼塊中的內容進行縮進。
if (someExpression){
??? DoSomething();
} - 要對case代碼塊進行縮進，盡管沒有使用花括號。
switch(someExpression){
??? case 0:
??????? DoSomething();
??? break;
??? ...
}
二、命名約定
- 要在命名標示符時遵循《框架設計準則》中的命名規范，除非是內部字段和私有字段。
- 要在命名空間、類型及成員時采用PascalCasing大小寫風格，除非是內部字段和私有字段。
- 要用camelCasing大小寫風格來命名內部字段和私有字段。
- 要用camelCasing大小寫風格來命名局部變量。
- 要用camelCasing大小寫風格來命名方法的形式參數。
- 不要使用匈牙利命名法（也就是說，不要在變量名中包含變量的類型）。
- 避免給局部變量加前綴。
- 要使用C#語言中對應的別名，不要使用.NET框架中的類型名。
例如，要使用int而不是Int32，要使用object而不是Object。
三、注釋
- 不要用注釋來描述一些對任何人都顯而易見的事。
- 避免使用塊注釋語法（/*...*/）。即使注釋會有多行，也最好是使用單行注釋語法（//...）。
//This is a very long content.
//This is a very long content.
//This is a very long content.
public class List<T> : IList<T>, IList{
??? ...
} - 不要把注釋放在行尾，除非注釋非常短。
//Avoid
public class ArrayList{
??? private int count;? //-1 indicates uninitialized array
}
四、文件的組織
- 不要在一個源文件中包含一個以上的公用類型，除非有嵌套類，或各類型之間的不同之處僅在于泛型參數的數量。
一個文件中有多個內部類型是允許的。 - 要用相同的名字來命名源文件及其包含的公用類型。
例如，String類應該在String.cs文件中，而List<T>類則應該在List.cs文件中。 - 要用相同的層次結構來組織文件目錄和名字空間。
例如，應該把System.Collections.Generic.List<T>的源文件放在System\Collections\Generic目錄中。 - 考慮根據下面給出的順序和組別來對成員進行分組：
1.所有字段。
2.所有構造函數。
3.公有屬性及其受保護的屬性。
4.方法。
5.事件。
6.所有顯式實現的接口成員。
7.內部成員。
8.私有成員。
9.所有嵌套類型。 - 要把不能公開訪問的成員和顯式實現的接口成員分別放在自己的#region塊中。
#region internal members
...
#endregion
#region private members
...
#endregion - 考慮在每個組別內根據字母順序來組織成員。
- 考慮根據由簡單到復雜的順序來組織重載成員。
- 要把using指令放在名字空間的聲明之外。
using System;
namespace System.Collections{
??? ...
}
轉載于:https://www.cnblogs.com/jacklaw/archive/2008/06/25/1229481.html
總結
- 上一篇： Page_Load Page_Init方
- 下一篇： C# Winform 带优美外观的Use