建议152：最少，甚至是不要注释 以往，我们在代码中不写上几行注释，就会被认为是钟不负责任的态度。现在，这种观点正在改变。试想，如果我们所有的命名全部采用有意义的单词或词组，注释还有多少存在的价值。 即便再详细的注释也不能优化糟糕的代码。并且注释往往不会随着代码的重构自动更新，有时候我们可能会在修改 ...
建议148：不重复代码 如果发现重复的代码，则意味着我们需要整顿一下，在继续前进。 重复的代码让我们的软件行为不一致。举例来说，如果存在两处相同的加密代码。结果在某一天，我们发现加密代码有个小Bug，然后修改了它，却又忘记了角落里的某处存在着一份相同的代码，那么这个Bug就会隐藏起来。 让我们重现这 ...
建议143：方法抽象级别应在同一层次 看下面代码： Init方法本意要完成初始化动作，而初始化包括本地初始化和远程初始化。这段代码中，Init方法内部代码的组织结构是本地初始化直接运行在方法内部，而远程初始化代码却被封装为一个方法在这里被调用。这显然是不妥当的，应为本地初始化和远程初始化的地位是相当 ...
建议137：委托和事件类型应添加上级后缀 委托类型本身是一个类，考虑让派生类的名字以基类名字作为后缀。事件类型是一类特殊的委托，所以事件类型也遵循本建议。 委托和事件的正确的命名方式有： 若果用传统方式，我们可能看不出来这些类型是有基类的，但是委托和事件的关键字delegate和event已经指明了 ...
建议135： 考虑使用肯定性的短语命名布尔属性 布尔值无非就是True和False，所以应该用肯定性的短语来表示它，例如，以Is、Can、Has作为前缀。 布尔属性正确命名的一个示例如下： 反面教材： 肯定性形容词或者短语虽然表达了一个肯定的含义，但是这些单词或者短语现在都被用于命名事件或者委托，所 ...
建议138：事件和委托变量使用动词或形容词短语命名 事件和委托使用场景是调用某个方法，只不过这个方法由调用者赋值。这决定了对应的变量应该以动词或形容词短语命名。 关于事件和委托变量妥当的命名示例如下： 这两个例子是WPF中Button类型，它们实际不是作为类型的字段出现的，而是作为事件访问器出现的： ...
建议151：使用事件访问器替换公开的事件成员变量 事件访问器包含两部分内容：添加访问器和删除访问器。如果涉及公开的事件字段，应该始终使用事件访问器。代码如下所示： 使用事件访问器的好处是，提供对赋值更多细粒度的控制。这就好比应该使用属性而不使用字段一样。所以下面的代码没有事件访问器灵活： 转自：《编 ...
建议140：使用默认的访问修饰符（我不太赞成作者的这个观点，这样减少的代码基本可以忽略不计，但是，如果把访问修饰符补充完整，反而会使代码更加易读。我认为自己写代码时应该尽量加上访问修饰符，看别人写的代码时能看懂就可以了。以下是作者的观点） 代码整洁的要求之一，就是尽量减少代码，我们从使用默认的访问修 ...
建议139：事件处理器命名采用组合方式 所谓事件处理器，就是实际被委托执行的那个方法。查看如下代码： 这段代码中，方法button_Click、button_SizeChanged、button_MouseDown即称作事件处理器。VS默认为我们生成的事件处理器的命名规则： 事件变量所属对象+下划线 ...
建议142：总是提供有意义的命名 除非有特殊原型，否则永远不要为自己的代码提供无意义的命名。 害怕需要过长的命名才能提供足够的意义？不要怕，其实我们更介意的是在代码的时候出现一个iTemp。 int i 这样的命名只能出现在循环中（如for循环），除此之外，我们找不到任何理由在代码的其他地方出现这样 ...
