一个优良的架构，个人认为不仅仅体现在设计的思想结构上，代码的命名规范也是至关重要的，一段的优雅的代码会让人看着赏心悦目，一个结构混乱，命名随意的代码会让人狂抓，尤其是在项目交接的时候，如果项目属于后者，那我只能说祝你好运了~
微软的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 member
private 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
{
// fields
int foo;
// constructors
public MyClass() { … }
// properties
public int Foo { get { … } set { … } }
// events
public event EventHandler FooChanged { add { … } remove { … } }
// methods
void DoSomething() { … }
void FindSomethind() { … }
//private interface implementations
void IFoo.DoSomething() { DoSomething(); }
// nested types
class NestedType { … }
}
}
