一個優良的架構，個人認為不僅僅體現在設計的思想結構上，代碼的命名規范也是至關重要的，一段的優雅的代碼會讓人看著賞心悅目，一個結構混亂，命名隨意的代碼會讓人狂抓，尤其是在項目交接的時候，如果項目屬于后者，那我只能說祝你好運了~
微軟的C#是結合眾多開發者心血的結晶，但是C# 的命名看上去貌似就是一個人寫的，每一行代碼都遵循相同的準則。所以說，一個實力出眾的公司都這么做，那么自己還有什么理由亂寫呢？編寫的代碼，不僅僅是自己查閱修改，別人也能會來查閱、學習，本著互聯網精神,我們更應該嚴格要求自己，讓代碼規范深深的烙印在我們潛意識中~

最近也讀到一篇文章 淺談軟件工程師的代碼素養，【素養】這個詞個人感覺在恰到不過了，素養二字不僅僅體現對技能的要求，又體現出一個軟件工程師對自身的高標準和完美代碼的追求（雖然這個世界上不存在完美的事情）~

因為Unity 2018.1 ：停止對MonoDevelop-Unity的支持，所以下面談到的命名方式是以微軟官方的命名方式為參考

相關地址

• https://docs.microsoft.com/zh-cn/dotnet/standard/design-guidelines/index
• https://msdn.microsoft.com/zh-cn/library/ms229002%28VS.80%29.aspx
• http://www.dofactory.com/reference/csharp-coding-standards
• https://blogs.msdn.microsoft.com/brada/2005/01/26/internal-coding-guidelines

---

有錯誤或者不準確的地方歡迎留言指正

---

風格指南

Tabs&縮進

Tab 字符(\0x09) 不應在代碼中使用。所有縮進應該用4個空格字符完成。（換句話說，一個Tab鍵的縮進應該用4個空格來代替）

Bracing

打開花括號總是應該在開始塊的語句后面的行首。大括號內容應縮進4個空格。例如：

if (SomeExpression){DoSomething();}else{DoSomethingElse();}

case”語句應該像switch語句一樣縮進：

switch (SomeNumber){case 0:DoSomething();break;case 1:DoSomethingElse();break;case 2:{int n = 1;DoAnotherThing(n);}break;}

大括號永遠不應被視為可選項。即使對于單個語句塊，您也應該始終使用大括號。這增加了代碼的可讀性和可維護性。(換句話說：就算一行函數也給老子加上大括號！！！)

for (int i=0; i<100; i++) { DoSomething(i); }

單行語句

單行語句可以有在同一條線上開始和結束的括號。

public class Foo {int bar;public int Bar{get { return bar; }set { bar = value; }} }

據建議，所有的控制結構（if, while, for, etc）使用大括號，但它不是必需的。

評論

評論應該用來描述意圖，算法概述和/或邏輯流程。 如果僅通過閱讀評論，作者以外的人可以理解功能的預期行為和一般操作，那將是理想的。雖然沒有最低評論要求，當然也有一些非常小的程序根本不需要評論，但希望大多數程序都會有反映程序員意圖和方法的評論。（就是說說這些函數干什么的，為什么這么寫，當時怎么想的）

版權聲明

每個文件都應以版權聲明開始。為了避免文檔評論構建中出現錯誤，您不希望使用三斜杠文檔評論，但使用XML可以使評論容易在未來取代。最終文本將因產品而異（您應該聯系法律確切的文字），但應該類似于：

//----------------------------------------------------------------------- // <copyright file="ContainerControl.cs" company="Microsoft"> // Copyright (c) Microsoft Corporation. All rights reserved. // </copyright> //-----------------------------------------------------------------------

文件評論 (可以理解為代碼注釋)

所有方法都應該使用XML文檔注釋。對于內部開發者評論，應該使用<devdoc>標簽

public class Foo { /// <summary>Public stuff about the method</summary> /// <param name=”bar”>What a neat parameter!</param> /// <devdoc>Cool internal stuff!</devdoc> /// public void MyMethod(int bar) { … } }

UNDONE§有一個大文檔，里面有我們應該使用的所有評論標簽......那是哪里？

評論風格

該//注釋標記（兩個斜杠）風格應該在大多數情況下使用。在可能的情況下，將注釋放在代碼上方而不是旁邊。 這里有些例子：

//這是WebClient通過代理工作所必需的 GlobalProxySelection.Select = new WebProxy("http://itgproxy"); //創建訪問Internet資源的對象 WebClient myClient = new WebClient();

當空間允許時，注釋可以放在行的末尾

public class SomethingUseful {private int itemHash; // instance memberprivate static bool hasDoneSomething; // static member }

間距

空間通過減少代碼密度來提高可讀性。以下是在代碼中使用空格字符的一些準則：

• 請在函數參數之間逗號后使用單個空格。

Right: Console.In.Read(myChar, 0, 1); Wrong: Console.In.Read(myChar,0,1);

• 不要在圓括號和函數參數后面使用空格

Right: CreateFoo(myChar, 0, 1) Wrong: CreateFoo( myChar, 0, 1 )

• 不要在函數名稱和括號之間使用空格。

Right: CreateFoo() Wrong: CreateFoo ()

• 不要在括號內使用空格

Right: x = dataArray[index]; Wrong: x = dataArray[ index ];

• 在流控制語句之前使用單個空格

Right: while (x == y) Wrong: while(x==y)

• 在比較運算符之前和之后使用單個空格

Right: if (x == y) Wrong: if (x==y)

命名

遵循內部和外部成員的所有.NET Framework設計指南。其中的要點包括：

• 不要使用匈牙利符號

• 不要為成員變量（，m，s_等）使用前綴。如果你想區分本地變量和成員變量，你應該在C＃中使用“this。”和“me。“在VB.NET中

• 請使用成員變量駝峰規則

• 請使用camelCasing作為參數

• 請使用局部變量駝峰規則

• 請使用PascalCasing的函數，屬性，事件和類名

• 接口名稱前綴加“I”

• 不要在枚舉，類或委托前加任何字母

擴展公共規則（沒有匈牙利語，沒有成員變量的前綴等）的原因是產生一致的源代碼外觀。另外一個目標是擁有干凈可讀的來源。代碼可讀性應該是主要目標。

命名約定

Interop類

Interop包裝器（DllImport語句）的類應遵循下面的命名約定：

• NativeMethods 不抑制非托管代碼屬性，這些方法可以在任何地方使用，因為將執行堆棧審核。

• UnsafeNativeMethods 禁止非托管代碼屬性。這些方法具有潛在的危險性，任何這些方法的調用者都必須進行全面的安全檢查，以確保使用安全并受到保護，因為不會執行堆棧審核。

• SafeNativeMethods 禁止非托管代碼屬性。這些方法是安全的，并且可以相當安全地使用，即使不執行堆棧審核，調用者也不需要進行全面的安全性評估

class NativeMethods {private NativeMethods() {}[DllImport(“user32”)]internal static extern void FormatHardDrive(string driveName); }[SuppressUnmanagedCode] class UnsafeNativeMethods {private UnsafeNativeMethods() {}[DllImport(“user32”)]internal static extern void CreateFile(string fileName); }[SuppressUnmanagedCode] class SafeNativeMethods {private SafeNativeMethods() {}[DllImport(“user32”)]internal static extern void MessageBox(string text); }

所有互操作類必須是私有的，所有方法都必須是內部的。另外應該提供一個私有構造函數來防止實例化。

文件組織

• 源文件應該只包含一個公共類型，盡管允許多個內部類

• 源文件應該被賦予文件中公共類的名稱

• 目錄名稱應該遵循該類的命名空間

例如，我期望在"System\Windows\Forms\Control.cs"找到公共類“System.Windows.Forms.Control”

• 類成員應該按照字母順序排列，并分組成部分（字段，構造函數，屬性，事件，方法，專用接口實現，嵌套類型）

• using語句應該在名稱空間聲明中

namespace MyNamespace {using System;public class MyClass : IFoo{// fieldsint foo;// constructorspublic MyClass() { … }// propertiespublic int Foo { get { … } set { … } }// eventspublic event EventHandler FooChanged { add { … } remove { … } }// methodsvoid DoSomething() { … }void FindSomethind() { … }//private interface implementationsvoid IFoo.DoSomething() { DoSomething(); }// nested typesclass NestedType { … }}}

總結

以上是生活随笔為你收集整理的Unity 之命名规范(一)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。