書接上回Unity 之命名規范(一)下面筆者說一些是示例和使用規范。在你自己的項目中可以使用這些或者根據自己的需要進行調整。
有錯誤或者不準確的地方歡迎留言指正
使用 PascalCasing 的類名稱和方法名稱
原因：與Microsoft的.NET Framework一致并且易于閱讀
public class ClientActivity
{
public void ClearStatistics()
{
//...
}
public void CalculateStatistics()
{
//...
}
}
使用camelCasing的方法參數和局部變量
原因：與Microsoft的.NET Framework一致并且易于閱讀
public class UserLog
{
public void Add(LogEvent logEvent)
{
int itemCount = logEvent.Items.Count;
// ...
}
}
不要在標識符中使用Hungarian 符號或者任何其他類型標識
原因：與Microsoft的.NET Framework和Visual Studio IDE一致，使得確定類型變得非常簡單（通過工具提示）。一般來說，你應該避免任何標識符中的類型指示符。
// 正確寫法
int counter;
string name;
// 錯誤寫法
int iCounter;
string strName;
不要將Screaming Caps（這個我也不知道怎么翻譯，大概的意思是全部大寫）用于常量或只讀變量
原因： 與微軟的.NET Framework一致。Screaming Caps過于密集不方便閱讀
// 正確
public static const string ShippingType = "DropShip";
// 錯誤
public static const string SHIPPINGTYPE = "DropShip";
避免使用縮寫。一般用到縮寫的地方如：Id, Xml, Ftp, URL(這個確實重要，例如：BT，在這項目中我怎么理解？！變態？按鈕？Big Tag？ WTF?。?！)
原因： 與Microsoft的.NET Framework保持一致并防止縮寫不一致。
// 正確
UserGroup userGroup;
Assignment employeeAssignment;
// 錯誤
UserGroup usrGrp;
Assignment empAssignment;
// 例外
CustomerId customerId;
XmlDocument xmlDocument;
FtpHelper ftpHelper;
UriPart uriPart;
使用PascalCasing縮寫3個或更多字符（2個字符都是大寫）
原因： 與微軟的.NET Framework一致。全部大寫在視覺上過度關注
HtmlHelper htmlHelper;
FtpTransfer ftpTransfer;
UIControl uiControl;
不要在標識符中使用下劃線
原因： 與微軟的.NET Framework一致，使代碼更加自然地閱讀
// 正確
public DateTime clientAppointment;
public TimeSpan timeLeft;
// 錯誤
public DateTime client_Appointment;
public TimeSpan time_Left;
使用 predefined type names 而不是系統類型名稱，如Int16, UInt64等
原因： 與Microsoft的.NET Framework一致，使代碼更加自然。
// 正確
string firstName;
int lastIndex;
bool isSaved;
// 錯誤
String firstName;
Int32 lastIndex;
Boolean isSaved;
使用隱式VAR局部變量聲明。例外：原始類型（int，string，double等）使用預定義的名稱。（不過筆者不建議這么弄，看上去表達不清晰,當然單從觀賞性來講Var是個不錯的選擇）
原因：消除混亂，特別是復雜的泛型類型。使用Visual Studio工具提示可輕松檢測類型。
var stream = File.Create(path);
var customers = new Dictionary();
// Exceptions
int index = 100;
string timeSheet;
bool isCompleted;
使用名詞或名詞短語來命名一個類
原因：與Microsoft的.NET Framework一致并且易于記憶。
public class Employee
{
}
public class BusinessLocation
{
}
public class DocumentCollection
{
}
用字母I 做接口的前綴（你要是不寫I編輯器都會提醒你 ）。接口名稱是名詞（短語）或形容詞。
原因：與微軟的.NET Framework一致。
public interface IShape
{
}
public interface IShapeCollection
{
}
public interface IGroupable
{
}
根據他們的主要類來命名源文件。例外：具有部分類的文件名反映它們的來源或目的，例如designer, generated等。(換句話說就是有嵌套類的時候命名按照他們父類的名稱來，例外說的就是見名知意，盡量減少讓閱讀者看到這個類猜這個類是干什么的~)
原因：符合微軟的做法。文件按字母順序排列，部分類保持相鄰。
// Located in Task.cs
public partial class Task
{
//...
}
// Located in Task.generated.cs
public partial class Task
{
//...
}
用一個清晰定義的結構來組織命名空間(就是說要分類劃分，就像動畫系統里面的命名功能不能寫到UI系統里面一樣)
原因：與微軟的.NET Framework一致。保持良好的代碼庫組織.
// Examples
namespace Company.Product.Module.SubModule
namespace Product.Module.Component
namespace Product.Layer.Module.Group
垂直對齊大括號。
class Program
{
static void Main(string[] args)
{
}
}
在類的頂部聲明所有成員變量，用在最高層的靜態變量。
原因： 普遍接受的做法，防止需要尋找變量聲明。
public class Account
{
public static string BankName;
public static decimal Reserves;
public string Number {get; set;}
public DateTime DateOpened {get; set;}
public DateTime DateClosed {get; set;}
public decimal Balance {get; set;}
// Constructor
public Account()
{
// ...
}
}
使用單數名字枚舉。例外：位字段枚舉。
原因：與Microsoft的.NET Framework一致，使代碼更加自然閱讀。多個標志，因為枚舉可以保存多個值（使用按位、或）。（這個筆記不是很清楚什么意思）
// Correct
public enum Color
{
Red,
Green,
Blue,
Yellow,
Magenta,
Cyan
}
// Exception
[Flags]
public enum Dockings
{
None = 0,
Top = 1,
Right = 2,
Bottom = 4,
Left = 8
}
明確指定枚舉的類型或枚舉的值（除了位域）
原因：在依賴實際類型和值時會造成混淆
// 錯誤
public enum Direction : long
{
North = 1,
East = 2,
South = 3,
West = 4
}
// 正確
public enum Direction
{
North,
East,
South,
West
}
不要在枚舉名稱后綴再次添Enum
原因：與Microsoft的.NET Framework保持一致，與在標識符中沒有類型指標的規則一致。（但是在unity中一般在Button的變量字段后綴都添加Button，例如Button openButton = null;）
// 錯誤
public enum CoinEnum
{
Penny,
Nickel,
Dime,
Quarter,
Dollar
}
// 正確
public enum Coin
{
Penny,
Nickel,
Dime,
Quarter,
Dollar
}
