#157个

【转】编写高质量代码改善C#程序的157个建议——建议156:利用特性为应用程序提供多个版本

 建议156:利用特性为应用程序提供多个版本基于如下理由,需要为应用程序提供多个版本:应用程序有体验版和完整功能版。应用程序在迭代过程中需要屏蔽一些不成熟的功能。假设我们的应用程序共有两类功能:第一类功能属于单机版,而第二类的完整版还提供了在线功能。那么,在功能上,需要定制两个属性“ONLINE&...

【转】编写高质量代码改善C#程序的157个建议——建议155:随生产代码一起提交单元测试代码

 建议155:随生产代码一起提交单元测试代码首先提出一个问题:我们害怕修改代码吗?是否曾经无数次面对乱糟糟的代码,下决心进行重构,然后在一个月后的某个周一,却收到来自测试版的报告:新的版本,没有之前的版本稳定,性能也更差了,Bug似乎也变多了。也就是说,重构的代码看上去质量更高了,可实际测试结果却不如人意。几...

【转】编写高质量代码改善C#程序的157个建议——建议154:不要过度设计,在敏捷中体会重构的乐趣

 建议154:不要过度设计,在敏捷中体会重构的乐趣有时候,我们不得不随时更改软件的设计:如果项目是针对某个大型机构的,不同级别的软件使用者,会提出不同的需求,或者随着关键岗位人员的更替,需求也会随个人意志有所变更。如果竞争对手增加了新需求,我们也不得不为正在研发的新产品调整设计方案。刚开始的架构太糟糕了,这可...

【转】编写高质量代码改善C#程序的157个建议——建议153:若抛出异常,则必须要注释

 建议153:若抛出异常,则必须要注释有一种必须加注释的场景,即使异常。如果API抛出异常,则必须给出注释。调用者必须通过注释才能知道如何处理那些专有的异常。通常,即便良好的命名也不可能告诉我们方法会抛出那些异常,在这种情况下,使用注释是最好的手段。///<summary>///注释///<...

【转】编写高质量代码改善C#程序的157个建议——建议152:最少,甚至是不要注释

 建议152:最少,甚至是不要注释以往,我们在代码中不写上几行注释,就会被认为是钟不负责任的态度。现在,这种观点正在改变。试想,如果我们所有的命名全部采用有意义的单词或词组,注释还有多少存在的价值。即便再详细的注释也不能优化糟糕的代码。并且注释往往不会随着代码的重构自动更新,有时候我们可能会在修改代码后忘记更...

【转】编写高质量代码改善C#程序的157个建议——建议151:使用事件访问器替换公开的事件成员变量

 建议151:使用事件访问器替换公开的事件成员变量事件访问器包含两部分内容:添加访问器和删除访问器。如果涉及公开的事件字段,应该始终使用事件访问器。代码如下所示:classSampleClass{EventHandlerListevents=newEventHandlerList();publiceventE...

【转】编写高质量代码改善C#程序的157个建议——建议150:使用匿名方法、Lambda表达式代替方法

 建议150:使用匿名方法、Lambda表达式代替方法方法体如果过小(如小于3行),专门为此定义一个方法就会显得过于繁琐。比如:staticvoidSampeMethod(){List<string>list=newList<string>(){"Mike","Rose","Steve...

【转】编写高质量代码改善C#程序的157个建议——建议149:使用表驱动法避免过长的if和switch分支

 建议149:使用表驱动法避免过长的if和switch分支随着代码变得复杂,我们很容易被过长的if和switch分支困扰。一个类枚举类型Week如下:enumWeek{Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday} 如果要把Week...

【转】编写高质量代码改善C#程序的157个建议——建议148:不重复代码

 建议148:不重复代码 如果发现重复的代码,则意味着我们需要整顿一下,在继续前进。重复的代码让我们的软件行为不一致。举例来说,如果存在两处相同的加密代码。结果在某一天,我们发现加密代码有个小Bug,然后修改了它,却又忘记了角落里的某处存在着一份相同的代码,那么这个Bug就会隐藏起来。让我们重现这个...

【转】编写高质量代码改善C#程序的157个建议——建议147:重构多个相关属性为一个类

 建议147:重构多个相关属性为一个类若存在多个相关属性,就应该考虑是否将其重构为一个类。查看如下类:classPerson{publicstringAddress{get;set;}publicstringZipCode{get;set;}publicstringMobile{get;set;}public...

【转】编写高质量代码改善C#程序的157个建议——建议146:只对外公布必要的操作

 建议146:只对外公布必要的操作那些没有必要公开的方法和属性要声明成private。如果需要公开的方法和属性超过9个,在VS默认的设置下,就需要滚屏才能显示在Intellisense中,如图:SampleClass类:classSampleClass{privateintfield1;privateintf...

【转】编写高质量代码改善C#程序的157个建议——建议145:避免过长的方法和过长的类

 建议145:避免过长的方法和过长的类 如果违反“一个方法只做一件事”及类型的“单一职责原则”,往往会产生过长的方法和过长的类。如果方法过长,意味着可以站在更高的层次上重构出若干更小的方法。以行数作为指标,有人建议一个方法不要超过10行,有人建议不要超...

【转】编写高质量代码改善C#程序的157个建议——建议144:一个方法只做一件事

 建议144:一个方法只做一件事“单一职责原则”(SRP)要求每一个类型只负责一件事情。我们将此概念扩展到方法上,就变成了:一个方法只做一件事。回顾上一建议的代码,LocalInit和RemoteInit方法是两件事情,但是在同一抽象层次上,在类型这个层次对外又可以将其归并为&ldqu...

【转】编写高质量代码改善C#程序的157个建议——建议143:方法抽象级别应在同一层次

 建议143:方法抽象级别应在同一层次看下面代码:classSampleClass{publicvoidInit(){//本地初始化代码1//本地初始化代码2RemoteInit();}voidRemoteInit(){//远程初始化代码1//远程初始化代码2}}  Init方法本意要完成...

【转】编写高质量代码改善C#程序的157个建议——建议142:总是提供有意义的命名

 建议142:总是提供有意义的命名 除非有特殊原型,否则永远不要为自己的代码提供无意义的命名。害怕需要过长的命名才能提供足够的意义?不要怕,其实我们更介意的是在代码的时候出现一个iTemp。inti这样的命名只能出现在循环中(如for循环),除此之外,我们找不到任何理由在代码的其他地方出现这样的无意...
首页上一页...45678...下一页尾页