代码的使用规范,或者说是代码编写的最佳“实践”(当然优良的格式规范也是一种最佳实践),它们是根据代码的实现/运行原理以及特定的应用场景进行实践的最佳方案,这些方案的使用除了可以提高代码的可读行外,还可以减少程序Bug、提高程序性能及安全性,如以下几个方面:
    使用语言特性
    this:使用this区分类型中的属性与变量、静态成员,可以提高程序可读性。
    var:适当的使用var可以提高开发效率且不影响程序可读性,如在不知道返回值具体类型或者不需要知道类型的时候。
    反例:

    1. var a = dictionary[key];
    2. // ...
    3. // ...
    4. var b = GetSomething(a);
    5. // ...
    6. // ...
    7. var c = b.Data;
    8. // ...
    9. // ...
    10. var d = Process(c, x, y, z);
    11. // ...
    12. // ...
    13. foreach (var e in d.Items)
    14. {
    15. //What the heck is e?
    16. }

    字符串内插(string interpolation):字符串内插是C#6.0的特性,使用字符串内插可以提高程序可读性:
    例:

    1. static void Main(string[] args)
    2. {
    3. var hello = "Hello";
    4. var world = "world";
    5. Console.WriteLine($"{hello}{world}");
    6. }

    异常
    当程序出现与预期不符时应该抛出异常让程序上游处理。
    尽可能使用C#中内置的异常类型。
    捕获异常必须处理。
    获取指定异常而非统一使用Exception。
    安全准则
    基于证据的安全性和代码访问安全性提供非常强大的显式机制来实现安全。 大多数应用程序代码就可以使用由.NET 实现的基础结构。 在某些情况下,需要额外的应用程序特定的安全性,或通过扩展安全系统或通过使用全新临时方法构建。
    使用.NET 强制执行权限和其他强制在代码中的,应建立屏障,以防止恶意代码访问您不希望其具有的信息或执行其他不需要的操作。 此外,必须在使用受信任代码的所有预期方案中平衡安全性和可用性。
    本概述介绍代码可以用于处理安全系统的不同方式。
    保护资源的访问
    设计和编写代码时,尤其是在使用或调用来源未知的代码时,需要保护和限制该代码对资源的访问。 因此,请记住以下可确保代码安全的方法:
    不使用代码访问安全性 (CAS)。
    不使用部分信任的代码。
    不要使用AllowPartiallyTrustedCaller特性 (APTCA)。
    不使用 .NET 远程处理。
    不使用分布式组件对象模型 (DCOM)。
    不使用二进制格式化程序。
    作为安全边界,部分受信任的代码不支持代码访问安全性和安全透明的代码。 建议在未实施其他安全措施的情况下,不要加载和执行未知来源的代码。 其他安全措施包括:
    虚拟化
    AppContainers
    操作系统 (OS) 用户和权限
    Hyper-V 容器
    安全性方面是非特定代码
    非特定于安全性的代码不对任何安全系统进行显示处理。 它通过所接收的任何权限来运行。 虽然无法捕获与受保护的操作 (例如,使用文件、 网络等) 相关联的安全异常的应用程序会在未经处理的异常,但安全性方面是非特定代码仍利用安全技术中的.NET.
    非特定于安全性的库具有你应了解的特殊性质。 假设你的库提供使用文件或调用非托管的代码的 API 元素。 如果你的代码不具有相应的权限,它不会运行所述。 但是,即使代码具有权限,调用它的任何应用程序代码必须具有相同的权限才能正常运行。 如果调用代码没有正确的权限,SecurityException作为代码访问安全堆栈审核的结果将显示。
    不是可重用组件的应用程序代码
    如果你的代码是由其他代码不会调用应用程序的一部分,安全很简单,不可能要求特殊的编码。 但请记住,恶意代码可以调用你的代码。 代码访问安全性可能会阻止恶意代码访问资源,而此类代码仍然可以读取你的字段或可能包含敏感信息的属性的值。
    此外,如果你的代码接受来自 Internet 或其他不可靠来源的用户输入,则务必要小心恶意输入。
    托管到本机代码实现的包装
    通常在这种情况下,某些有用功能是在你想要提供给托管代码的本机代码中实现的。 托管包装器可通过使用平台调用或 COM 互操作轻松写入。 但如果你这样做,包装器的调用方必须具有非托管代码权限才能成功。 在默认策略下,这意味着代码下载从 intranet 或 Internet 不适用于此包装器。
    而不是授予非托管的代码权限的所有应用程序使用这些包装器,则最好仅对包装器代码将这些权限授予。 如果基础功能没有公开任何资源,且实现同样也安全,则包装器只需断言其权限,这可使任何代码通过它进行调用。 当涉及资源时,安全编码应该与下一节中所述的库代码案例相同。 因为包装器可能对这些资源公开调用方,所以仔细验证本机代码的安全性是必要的,这是包装器的责任。
    库代码的公开受保护的资源
    下面的方法是最强大的因此具有潜在危险 (如果正确执行) 对安全编码: 你的库作为其他代码访问某些资源不可否则,就像.NET 类强制实施的接口它们使用的资源的权限。 只要公开资源,你的代码首先就必须要求相应资源的权限(也就是说,必须执行安全检查),然后通常断言其权限来执行实际的操作。
    代码使用规范是一个广泛的话题,除了以上一些通用的规范之外,还可以对OOP以及开发框架等方面根据实际情况制定规则,使用统一的规范进行开发可以让代码变得更加容易管理。