摘要: 建议157:从写第一个界面开始,就进行自动化测试 如果说单元测试是白盒测试,那么自动化测试就是黑盒测试。黑盒测试要求捕捉界面上的控件句柄,并对其进行编码,以达到模拟人工操作的目的。具体的自动化测试请学习Code UI Automation,这里不再介绍。 转自:《编写高质量代码改善C#程序的157个 阅读全文
posted @ 2017-12-11 11:34 指间的徘徊 阅读(771) 评论(0) 推荐(0) 编辑
摘要: 建议156:利用特性为应用程序提供多个版本 基于如下理由,需要为应用程序提供多个版本: 应用程序有体验版和完整功能版。 应用程序在迭代过程中需要屏蔽一些不成熟的功能。 假设我们的应用程序共有两类功能:第一类功能属于单机版,而第二类的完整版还提供了在线功能。那么,在功能上,需要定制两个属性“ONLIN 阅读全文
posted @ 2017-12-11 11:32 指间的徘徊 阅读(506) 评论(0) 推荐(0) 编辑
摘要: 建议155:随生产代码一起提交单元测试代码 首先提出一个问题:我们害怕修改代码吗?是否曾经无数次面对乱糟糟的代码,下决心进行重构,然后在一个月后的某个周一,却收到来自测试版的报告:新的版本,没有之前的版本稳定,性能也更差了,Bug似乎也变多了。也就是说,重构的代码看上去质量更高了,可实际测试结果却不 阅读全文
posted @ 2017-12-11 11:30 指间的徘徊 阅读(384) 评论(0) 推荐(0) 编辑
摘要: 建议154:不要过度设计,在敏捷中体会重构的乐趣 有时候,我们不得不随时更改软件的设计: 如果项目是针对某个大型机构的,不同级别的软件使用者,会提出不同的需求,或者随着关键岗位人员的更替,需求也会随个人意志有所变更。 如果竞争对手增加了新需求,我们也不得不为正在研发的新产品调整设计方案。 刚开始的架 阅读全文
posted @ 2017-12-11 11:29 指间的徘徊 阅读(406) 评论(0) 推荐(0) 编辑
摘要: 建议153:若抛出异常,则必须要注释 有一种必须加注释的场景,即使异常。如果API抛出异常,则必须给出注释。调用者必须通过注释才能知道如何处理那些专有的异常。通常,即便良好的命名也不可能告诉我们方法会抛出那些异常,在这种情况下,使用注释是最好的手段。 转自:《编写高质量代码改善C#程序的157个建议 阅读全文
posted @ 2017-12-11 11:28 指间的徘徊 阅读(319) 评论(0) 推荐(0) 编辑
摘要: 建议152:最少,甚至是不要注释 以往,我们在代码中不写上几行注释,就会被认为是钟不负责任的态度。现在,这种观点正在改变。试想,如果我们所有的命名全部采用有意义的单词或词组,注释还有多少存在的价值。 即便再详细的注释也不能优化糟糕的代码。并且注释往往不会随着代码的重构自动更新,有时候我们可能会在修改 阅读全文
posted @ 2017-12-11 11:27 指间的徘徊 阅读(376) 评论(0) 推荐(0) 编辑
摘要: 建议151:使用事件访问器替换公开的事件成员变量 事件访问器包含两部分内容:添加访问器和删除访问器。如果涉及公开的事件字段,应该始终使用事件访问器。代码如下所示: 使用事件访问器的好处是,提供对赋值更多细粒度的控制。这就好比应该使用属性而不使用字段一样。所以下面的代码没有事件访问器灵活: 转自:《编 阅读全文
posted @ 2017-12-11 11:26 指间的徘徊 阅读(287) 评论(0) 推荐(0) 编辑
摘要: 建议150:使用匿名方法、Lambda表达式代替方法 方法体如果过小(如小于3行),专门为此定义一个方法就会显得过于繁琐。比如: 上面的代码中,SampleMethod方法需要完成的功能是查看list中有没有长度等于5的元素。Predicate是一个委托,它接收元素值,并返回元素是否符合要求这一结果 阅读全文
posted @ 2017-12-11 11:23 指间的徘徊 阅读(387) 评论(0) 推荐(0) 编辑
摘要: 建议149:使用表驱动法避免过长的if和switch分支 随着代码变得复杂,我们很容易被过长的if和switch分支困扰。 一个类枚举类型Week如下: 如果要把Week的元素值用中文输出,简单而丑陋的方法也许是封装一个GetChineseWeek方法: 之所以说这种方法太丑陋,是因为: 1)分支太 阅读全文
posted @ 2017-12-11 11:15 指间的徘徊 阅读(565) 评论(0) 推荐(0) 编辑
摘要: 建议148:不重复代码 如果发现重复的代码,则意味着我们需要整顿一下,在继续前进。 重复的代码让我们的软件行为不一致。举例来说,如果存在两处相同的加密代码。结果在某一天,我们发现加密代码有个小Bug,然后修改了它,却又忘记了角落里的某处存在着一份相同的代码,那么这个Bug就会隐藏起来。 让我们重现这 阅读全文
posted @ 2017-12-11 11:13 指间的徘徊 阅读(300) 评论(0) 推荐(0) 编辑
摘要: 建议147:重构多个相关属性为一个类 若存在多个相关属性,就应该考虑是否将其重构为一个类。查看如下类: 上面代码中的这四个属性全部跟联系方式有关,所以,我们应该重构一个Contact类型,代码如下所示: 记住,类型中的相关属性超过3个,就可以考虑将其重构为一个类了。 转自:《编写高质量代码改善C#程 阅读全文
posted @ 2017-12-11 11:12 指间的徘徊 阅读(256) 评论(0) 推荐(0) 编辑
摘要: 建议146:只对外公布必要的操作 那些没有必要公开的方法和属性要声明成private。如果需要公开的方法和属性超过9个,在VS默认的设置下,就需要滚屏才能显示在Intellisense中,如图: SampleClass类: class SampleClass { private int field1 阅读全文
posted @ 2017-12-11 11:10 指间的徘徊 阅读(257) 评论(0) 推荐(0) 编辑
摘要: 建议145:避免过长的方法和过长的类 如果违反“一个方法只做一件事”及类型的“单一职责原则”,往往会产生过长的方法和过长的类。 如果方法过长,意味着可以站在更高的层次上重构出若干更小的方法。以行数作为指标,有人建议一个方法不要超过10行,有人建议不要超过30行。当然,这没有唯一标准。在我看了,一个方 阅读全文
posted @ 2017-12-11 11:09 指间的徘徊 阅读(536) 评论(0) 推荐(0) 编辑
摘要: 建议144:一个方法只做一件事 “单一职责原则”(SRP)要求每一个类型只负责一件事情。我们将此概念扩展到方法上,就变成了:一个方法只做一件事。 回顾上一建议的代码,LocalInit和RemoteInit方法是两件事情,但是在同一抽象层次上,在类型这个层次对外又可以将其归并为“初始化”这一件事情上 阅读全文
posted @ 2017-12-11 11:08 指间的徘徊 阅读(266) 评论(0) 推荐(0) 编辑
摘要: 建议143:方法抽象级别应在同一层次 看下面代码: Init方法本意要完成初始化动作,而初始化包括本地初始化和远程初始化。这段代码中,Init方法内部代码的组织结构是本地初始化直接运行在方法内部,而远程初始化代码却被封装为一个方法在这里被调用。这显然是不妥当的,应为本地初始化和远程初始化的地位是相当 阅读全文
posted @ 2017-12-11 11:06 指间的徘徊 阅读(264) 评论(0) 推荐(0) 编辑
摘要: 建议142:总是提供有意义的命名 除非有特殊原型,否则永远不要为自己的代码提供无意义的命名。 害怕需要过长的命名才能提供足够的意义?不要怕,其实我们更介意的是在代码的时候出现一个iTemp。 int i 这样的命名只能出现在循环中(如for循环),除此之外,我们找不到任何理由在代码的其他地方出现这样 阅读全文
posted @ 2017-12-11 11:05 指间的徘徊 阅读(220) 评论(0) 推荐(0) 编辑
摘要: 建议141:不知道该不该用大括号时,就用 如果if条件语句只有一行语句,要不要使用大括号? 答案是:建议使用。一个括号不会增加多少代码,但是却让代码看上去增加了一致性。括号本身只会让代码更具条理性。 转自:《编写高质量代码改善C#程序的157个建议》陆敏技 阅读全文
posted @ 2017-12-11 11:04 指间的徘徊 阅读(325) 评论(0) 推荐(0) 编辑
摘要: 建议140:使用默认的访问修饰符(我不太赞成作者的这个观点,这样减少的代码基本可以忽略不计,但是,如果把访问修饰符补充完整,反而会使代码更加易读。我认为自己写代码时应该尽量加上访问修饰符,看别人写的代码时能看懂就可以了。以下是作者的观点) 代码整洁的要求之一,就是尽量减少代码,我们从使用默认的访问修 阅读全文
posted @ 2017-12-11 11:02 指间的徘徊 阅读(322) 评论(1) 推荐(0) 编辑
摘要: 建议139:事件处理器命名采用组合方式 所谓事件处理器,就是实际被委托执行的那个方法。查看如下代码: 这段代码中,方法button_Click、button_SizeChanged、button_MouseDown即称作事件处理器。VS默认为我们生成的事件处理器的命名规则: 事件变量所属对象+下划线 阅读全文
posted @ 2017-12-11 10:41 指间的徘徊 阅读(275) 评论(0) 推荐(0) 编辑
摘要: 建议138:事件和委托变量使用动词或形容词短语命名 事件和委托使用场景是调用某个方法,只不过这个方法由调用者赋值。这决定了对应的变量应该以动词或形容词短语命名。 关于事件和委托变量妥当的命名示例如下: 这两个例子是WPF中Button类型,它们实际不是作为类型的字段出现的,而是作为事件访问器出现的: 阅读全文
posted @ 2017-12-11 10:39 指间的徘徊 阅读(330) 评论(0) 推荐(0) 编辑