摘要：
建议149：使用表驱动法避免过长的if和switch分支 随着代码变得复杂，我们很容易被过长的if和switch分支困扰。 一个类枚举类型Week如下： 如果要把Week的元素值用中文输出，简单而丑陋的方法也许是封装一个GetChineseWeek方法： 之所以说这种方法太丑陋，是因为： 1）分支太 阅读全文
摘要：
建议148：不重复代码 如果发现重复的代码，则意味着我们需要整顿一下，在继续前进。 重复的代码让我们的软件行为不一致。举例来说，如果存在两处相同的加密代码。结果在某一天，我们发现加密代码有个小Bug，然后修改了它，却又忘记了角落里的某处存在着一份相同的代码，那么这个Bug就会隐藏起来。 让我们重现这 阅读全文
摘要：
建议147：重构多个相关属性为一个类 若存在多个相关属性，就应该考虑是否将其重构为一个类。查看如下类： 上面代码中的这四个属性全部跟联系方式有关，所以，我们应该重构一个Contact类型，代码如下所示： 记住，类型中的相关属性超过3个，就可以考虑将其重构为一个类了。 转自：《编写高质量代码改善C#程 阅读全文
摘要：
建议146：只对外公布必要的操作 那些没有必要公开的方法和属性要声明成private。如果需要公开的方法和属性超过9个，在VS默认的设置下，就需要滚屏才能显示在Intellisense中，如图： SampleClass类： class SampleClass { private int field1 阅读全文
摘要：
建议145：避免过长的方法和过长的类 如果违反“一个方法只做一件事”及类型的“单一职责原则”，往往会产生过长的方法和过长的类。 如果方法过长，意味着可以站在更高的层次上重构出若干更小的方法。以行数作为指标，有人建议一个方法不要超过10行，有人建议不要超过30行。当然，这没有唯一标准。在我看了，一个方 阅读全文
摘要：
建议144：一个方法只做一件事 “单一职责原则”（SRP）要求每一个类型只负责一件事情。我们将此概念扩展到方法上，就变成了：一个方法只做一件事。 回顾上一建议的代码，LocalInit和RemoteInit方法是两件事情，但是在同一抽象层次上，在类型这个层次对外又可以将其归并为“初始化”这一件事情上 阅读全文
摘要：
建议143：方法抽象级别应在同一层次 看下面代码： Init方法本意要完成初始化动作，而初始化包括本地初始化和远程初始化。这段代码中，Init方法内部代码的组织结构是本地初始化直接运行在方法内部，而远程初始化代码却被封装为一个方法在这里被调用。这显然是不妥当的，应为本地初始化和远程初始化的地位是相当 阅读全文
摘要：
建议142：总是提供有意义的命名 除非有特殊原型，否则永远不要为自己的代码提供无意义的命名。 害怕需要过长的命名才能提供足够的意义？不要怕，其实我们更介意的是在代码的时候出现一个iTemp。 int i 这样的命名只能出现在循环中（如for循环），除此之外，我们找不到任何理由在代码的其他地方出现这样 阅读全文
摘要：
建议141：不知道该不该用大括号时，就用 如果if条件语句只有一行语句，要不要使用大括号？ 答案是：建议使用。一个括号不会增加多少代码，但是却让代码看上去增加了一致性。括号本身只会让代码更具条理性。 转自：《编写高质量代码改善C#程序的157个建议》陆敏技 阅读全文
摘要：
建议140：使用默认的访问修饰符（我不太赞成作者的这个观点，这样减少的代码基本可以忽略不计，但是，如果把访问修饰符补充完整，反而会使代码更加易读。我认为自己写代码时应该尽量加上访问修饰符，看别人写的代码时能看懂就可以了。以下是作者的观点） 代码整洁的要求之一，就是尽量减少代码，我们从使用默认的访问修 阅读全文