C#(.NET)中有关编码的一些建议，原文地址：

目录

介绍

开发者之间经常喜欢争论“编码规范”，在整个项目周期中严格遵守编码规范是非常重要的。每个人都应该认识到这种约定是非常有用的，接下来我给大家分享一下这些年来我总结的一些编码规范，，有些很基础但是对我们非常有用。

试一试

我们先举一个FizzBuzz的例子。现在我们需要写一段代码遍历1到100，如果遍历到的数值是3的倍数，那么输出“Fizz”，如果是5的倍数则输出“Buzz”，如果既是3的倍数也是5的倍数则输出“FizzBuzz”。其余情况下将原数值直接输出。

Examp1：

你觉得上面这段代码怎么样？我们可否写得更好一些呢？

Example2：

现在你觉得这段代码怎么样？我们可否还能写得再好一点呢？

好吧，让我来再将这段代码优化一下。命名这种事是我们工作中最困难的事情之一，因为我们要花很多时间来取名，属性、类、文件以及项目等等。其实我们也应该多花一些时间在命名这件事情上，因为一个好的名称可以具有显而易见的含义，让人一看就懂。

现在觉得怎么样？是不是比之前的例子都好，可读性更强了？

什么是更好的代码？

先为人而写代码，其次再为计算机。编写易读的代码比编写复杂难懂的代码用时长不了多少，至少从长远来看。如果你的代码很容易读懂，那么它肯定会工作得很好（译者注：这里指可读性好的代码说明思路清晰，逻辑大部分不会有问题）。这也是要编写易读代码的重要原因。另外，在我们回顾之前写的旧代码时，在别人需要修复一些bug时，在别人需要将你写的一部分代码移植到别的系统中时，也都需要能够读懂我们之前写的源码。

“如果我们只为自己而写代码，为什么还要求编写易读懂的代码呢？”

好吧，如果一个礼拜或者两个礼拜后，你要开发别的系统了（你不再负责原项目了）。那么其他人怎样修复原项目中的bug呢？（过这么长时间后）我想你大概也会完全迷失在你曾经写的糟糕代码之中吧。

我个人觉得，好代码应该包含以下特征：

代码容易被修改，容易在原有基础上进行扩展；

代码清晰简洁并能够表达清楚含义；

代码质量高。

所以，请在满足机器需求的前提下，尽量编写更容易读懂的代码。

怎样提高代码的可读性？

首先你得多阅读他人写的代码，然后能够分辨出哪些是好的习惯哪些不是，什么编码风格能让你更容易读懂而什么让你更迷糊，接着将这些好的编码方式应用到自己的代码之中，当然最后你还是需要一些时间、一些经验以及多一些实践来提高你代码的可读性。

对于每个软件公司来说，让员工遵守一个好的编码标准是非常重要的，这可以通过一些培训、员工之间代码相互检查等方式来达到目的。下面介绍几款自动化代码检查工具：

FxCop

StyleCop

JetBrains ReSharper

什么是编码规范？

根据维基百科上的解释：编码规范是指针对某一种编程语言而总结出来的一系列编码指南，旨在约束人们的编码风格、编码实践以及书写每一段代码的方式。这些规范几乎涉及到文件组织、缩进、注释、声明、命名方式、编程原则等等各方面。软件开发者被要求严格遵守这些规则，从而提高源代码的可读性并使软件系统更易维护。编码规范可以以文档的形式分发给每个员工，每个编码人员必须遵守。注意编码规范对于编译器来讲并不是强制性的，因此编码过程中不遵守编码规范并不会影响软件系统的正常运行。

你可能知道类名、方法名、局部变量名以及属性名之间的命名区别，因为它们通常使用不同的大小写规范。你可以在互联网上找到一门编程语言的编码指南，所以找到它并遵守它吧。

下面这些编码指南是微软团队指定的，我仅仅是增加了一些附加内容。

大写规范

下面是C#编程中的一些例子，命名规范以及最佳实践。大家可以参考。

PascalCasing

标识符中的每个单词的首字母均大写。

CamelCasing

标识符中的第一个单词首字母小写，其余单词首字母大写。

参见：https://msdn.microsoft.com/en-us/library/ms229043.aspx

一些命名示例

在互联网上你可以找到足够多的资料，我仅仅列举出一部分：

下面是我总结的一些最基本的规范：

1）对于类、方法、属性等，请使用PascalCasing方式

2）对于参数和局部变量，请使用CamelCasing方式

3）不要使用缩写（这里应该是毫无根据的缩写，不能很直观的看出意思，译者注）

4）在标识符中不要使用下划线

5）在接口名称前加I字母

6）类成员变量声明在类的最前面，其中静态成员在最上

7）枚举值使用单一的名称

8）枚举类型名称后不要加Enum后缀

开发者应该遵守的一些重要规范

不要定义太大的类