.NET框架-微軟C#程式設計風格官方指南
作者:vuefine
文獻:msdn library
平臺:.NET 2.0+
from ms official guideline:
1 We use Allman style braces, where each brace begins on a new line.
while (x == y)
{
something();
somethingelse();
}
finalthing();
2 We use four spaces of indentation (no tabs).
3 We use camelCase for internal and private fields and use readonly where possible. Prefix instance fields with , static fields with s_ and thread static fields with t_. When used on static fields, readonly should come after static (i.e. static readonly not readonly static).
4 We avoid this. unless absolutely necessary.
5 We always specify the visibility, even if it’s the default. Visibility should be the first modifier.
private string _foo //better
string _foo //bad
public abstract //better
abstract public //bad
6 Namespace imports should be specified at the top of the file, outside of namespace declarations and should be sorted alphabetically.
using System.IO;
using System.Collections;
namespace CAXA.MES.UI.Performance.Board
{
public class LinkedList
{
}
}
7 Avoid more than one empty line at any time. For example, do not have two blank lines between members of a type.
8 Avoid spurious free spaces.
if (someVar == 0)...,
9 If a file happens to differ in style from these guidelines (e.g. private members are named m_member rather than _member), the existing style in that file takes precedence.
10 We only use var when it’s obvious what the variable type is.
var stream = new FileStream(...) //var is OKay
var stream = OpenStandardInput() // here var is not good
11 We use language keywords instead of BCL types.
int, string, float // good
Int32, String, Single // bad
12 We use PascalCasing to name all our constant local variables and fields. The only exception is for interop code where the constant value should exactly match the name and value of the code you are calling via interop.
private const int Age=100; //good
13 We use nameof(…) instead of “…” whenever possible and relevant.
14 Fields should be specified at the top within type declarations.
15 When including non-ASCII characters in the source code use Unicode escape sequences (\uXXXX) instead of literal characters.
相關文章
- JavaScript 程式設計風格指南JavaScript程式設計
- Google Java 程式設計風格指南GoJava程式設計
- RayWenderlich 官方 Swift 風格指南Swift
- Google Python 程式設計風格指南GoPython程式設計
- Google C++程式設計風格指南GoC++程式設計
- Google C++ 程式設計風格指南:類GoC++程式設計
- Google C++ 程式設計風格指南:格式GoC++程式設計
- Google C++ 程式設計風格指南:作用域GoC++程式設計
- Google C++ 程式設計風格指南:註釋GoC++程式設計
- Google C++程式設計風格指南(七):格式GoC++程式設計
- Google C++ 程式設計風格指南:命名約定GoC++程式設計
- Google Java 程式設計風格指南 —— 見微知著GoJava程式設計
- Google C++程式設計風格指南(二):作用域GoC++程式設計
- Javascript程式設計風格JavaScript程式設計
- Google C++程式設計風格指南(六):程式碼註釋GoC++程式設計
- Google C++ 程式設計風格指南:標頭檔案GoC++程式設計
- Google C++ 程式設計風格指南:其他 C++ 特性GoC++程式設計
- Google C++程式設計風格指南(三):C++ 類GoC++程式設計
- Google C++程式設計風格指南(五):命名約定GoC++程式設計
- JavaScript 程式碼風格指南JavaScript
- 糟糕程式設計師的程式設計風格程式設計師
- Google C++ 程式設計風格指南:來自 Google 的奇技GoC++程式設計
- Google C++程式設計風格指南(八):規則之例外GoC++程式設計
- 物件導向程式設計風格 VS 基於物件程式設計風格(boost::bind/function)物件程式設計Function
- Vue 前端程式碼風格指南Vue前端
- Google JavaScript 程式碼風格指南GoJavaScript
- Python程式設計風格和設計模式Python程式設計設計模式
- 優秀Java程式設計師的程式設計風格Java程式設計師
- 設計團隊必看!教你10招搞定web設計風格指南Web
- 各種流行的程式設計風格程式設計
- 前端 JavaScript 程式設計風格淺析前端JavaScript程式設計
- 你需要懂點程式設計風格程式設計
- 程式設計師高逼格指南程式設計師
- REST設計風格REST
- JS 風格指南JS
- JavaScript風格指南JavaScript
- java程式設計規約----程式碼風格(一)Java程式設計
- .NET框架設計(常被忽視的C#設計技巧)框架C#