摘要：
建议141：不知道该不该用大括号时，就用如果if条件语句只有一行语句，要不要使用大括号？答案是：建议使用。一个括号不会增加多少代码，但是却让代码看上去增加了一致性。括号本身只会让代码更具条理性。转自：《编写高质量代码改善C#程序的157个建议》陆敏技 阅读全文
摘要：
建议140：使用默认的访问修饰符（我不太赞成作者的这个观点，这样减少的代码基本可以忽略不计，但是，如果把访问修饰符补充完整，反而会使代码更加易读。我认为自己写代码时应该尽量加上访问修饰符，看别人写的代码时能看懂就可以了。以下是作者的观点）代码整洁的要求之一，就是尽量减少代码，我们从使用默认的访问修饰... 阅读全文
摘要：
建议139：事件处理器命名采用组合方式所谓事件处理器，就是实际被委托执行的那个方法。查看如下代码： public MainWindow() { InitializeComponent(); Button button = new... 阅读全文
摘要：
建议138：事件和委托变量使用动词或形容词短语命名事件和委托使用场景是调用某个方法，只不过这个方法由调用者赋值。这决定了对应的变量应该以动词或形容词短语命名。关于事件和委托变量妥当的命名示例如下： public event RoutedEventHandler Click; ... 阅读全文
摘要：
建议137：委托和事件类型应添加上级后缀委托类型本身是一个类，考虑让派生类的名字以基类名字作为后缀。事件类型是一类特殊的委托，所以事件类型也遵循本建议。委托和事件的正确的命名方式有： public delegate void HttpContinueDelegate(int statusCod... 阅读全文
摘要：
建议136：优先使用后缀表示已有类型的新版本加后缀在某些情况下是很奇怪的形式，我们都不愿意看到OrderProcessor2这样的类型。但是，有的时候仍旧有必要这样做。最典型的是FCL中关于数字证书操作的X509Certificate和X509Certificate2这两个类型。X509Certif... 阅读全文
摘要：
建议135： 考虑使用肯定性的短语命名布尔属性布尔值无非就是True和False，所以应该用肯定性的短语来表示它，例如，以Is、Can、Has作为前缀。布尔属性正确命名的一个示例如下： class SampleClass { public bool IsEnabled { ... 阅读全文
摘要：
建议134：有条件地使用前缀在.NET的设计规范中，不建议使用前缀。但是，即便是微软自己依然广泛的使用这前缀。最典型的前缀是m_，这种命名一方面是考虑到历史沿革中的习惯问题，另一方面也许我们确实有必要这么做。在一个不是很庞大的类型中，我们确实不应该使用任何前缀。各类设计规范也总建议我们保持一个娇小的... 阅读全文
摘要：
建议133：用camelCasing命名私有字段和局部变量私有变量和局部变量只对本类型负责，它们在命名方式也采用和开放的属性及字段不同的方法。camelCasing很适合这类命名。camelCasing和PascalCasing的区别是它的首字母是小写的。之所以要采用这两种不同的命名规则，是为了便于... 阅读全文
摘要：
建议132：考虑用类名作为属性名一般来说，若果属性对应一个类型，应该直接用类型名命名属性名。如下： class Person { public Company Company { get; set; } } class Company { /... 阅读全文
摘要：
建议131：用PascalCasing命名公开元素开放给调用者的属性、字段和方法都应该采用PascalCasing命名方法，比如： class Person { public string FirstName; public string LastName; ... 阅读全文
摘要：
建议130：以复数命名枚举类型，以单数命名枚举元素枚举类型应该具有负数形式，它表达的是将一组相关元素组合起来的语义。比如： enum Week { Monday, Tuesday, Wednesday, Thursday, ... 阅读全文
摘要：
建议129：泛型类型参数要以T作为前缀作为一种约定，泛型类型的参数要以T作为前缀。如委托声明：Action其中，泛型类型参数名不应该处理成：Action当然，这仅仅是一种习惯，若果使用第二种命名方式，编译器并不会报错，但是作为调用者，也许不能意识到这里是一个泛型类型参数。这个问题在为类型指定泛型的时... 阅读全文
摘要：
建议128：考虑让派生类的名字以基类名字作为后缀派生类的名字可以考虑以基类名字作为后缀。这带来的好处是，从类型的名字上我们就知道它包含在哪一个继承体系中。Exception及其子类就是这样一个典型的例子。所有的异常都应该继承自System.Exception，而所有的异常都应该命名为Customed... 阅读全文
摘要：
建议127：用形容词组给接口命名接口规范的是“Can do”，也就是说，它规范的是类型可以具有哪些行为。所以，接口的命名应该是一个形容词，如：IDisposable表示可以被释放IEnumerable表示类型含有Items，可以被迭代。正是因为接口表示的是类型的行为，所以从语义上可以让类型继承多个接... 阅读全文
摘要：
建议126：用名词和名词组给类型命名类型对应着现实世界中的实际对象。对象在语言中意味着它是一个名词。所以，类型也应该以名词或名词词组去命名。类型定义了属性和行为。虽然它包含行为，但不是行为本身。所以，下面的一些命名对于类型来说是好的命名：OrderProcessorScoreManagerCours... 阅读全文
摘要：
建议125：避免用FCL的类型名称命名自己的类型试想过自己写一个Socket类型吗？如果没有，我们来尝试一下：public class Socket{ //省略 }把以上代码同某些其他工具类封装到某个dll里，让其他人调用。调用者代码如下：public class SampleInvoker{ ... 阅读全文
摘要：
建议124：考虑在命名空间中使用复数如果有一组功能相近的类型被分到了同一个命名空间想，可以考虑为命名空间使用复数。最典型的例子有，在FCL中，我们需要把所有的非泛型集合类集中在一起存放，所以就有了System.Collections命名空间。这样的命名规范，好处是即便没有使用过集合类的人，看到这个命... 阅读全文
摘要：
建议123：程序集不必与命名空间同名程序集一般会和命名空间同名，但这并不是必须的。事实上，不同名的命名空间和程序集是很常见的。程序集表示的是一种物理上的分组，而命名空间是逻辑上的分组，两者没有必然联系。当然，如果项目最终会被编译为dll，则我们更建议程序集和命名空间命名保持一致，这看上去更符合习惯。... 阅读全文
摘要：
建议122：以.为命名空间命名建议以.为程序集命名，比如Microsoft.Windows.Design。这有助于唯一地标识我们的命名空间。另外一种有效且肯定是唯一的表示命名空间的方式是使用域名。假设我们的域名是www.microsoft.com，那么命名空间应该命名为Com.Microsoft.。... 阅读全文