侯文成-CSDN博客

转载建议157：从写第一个界面开始，就进行自动化测试

建议157：从写第一个界面开始，就进行自动化测试如果说单元测试是白盒测试，那么自动化测试就是黑盒测试。黑盒测试要求捕捉界面上的控件句柄，并对其进行编码，以达到模拟人工操作的目的。具体的自动化测试请学习Code UI Automation，这里不再介绍。转自：《编写高质量代码改善C#程序的157个建议》陆敏技

2016-09-14 11:10:29 580

转载建议156：利用特性为应用程序提供多个版本

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

2016-09-14 11:10:01 533

转载建议155：随生产代码一起提交单元测试代码

建议155：随生产代码一起提交单元测试代码首先提出一个问题：我们害怕修改代码吗？是否曾经无数次面对乱糟糟的代码，下决心进行重构，然后在一个月后的某个周一，却收到来自测试版的报告：新的版本，没有之前的版本稳定，性能也更差了，Bug似乎也变多了。也就是说，重构的代码看上去质量更高了，可实际测试结果却不如人意。几乎每个程序员都因为此类问题纠结过。我们要修改的代码也许来自某些不负责任或经验

2016-09-14 11:09:48 1026

转载建议154：不要过度设计，在敏捷中体会重构的乐趣

建议154：不要过度设计，在敏捷中体会重构的乐趣有时候，我们不得不随时更改软件的设计：如果项目是针对某个大型机构的，不同级别的软件使用者，会提出不同的需求，或者随着关键岗位人员的更替，需求也会随个人意志有所变更。如果竞争对手增加了新需求，我们也不得不为正在研发的新产品调整设计方案。刚开始的架构太糟糕了，这可能源于设计经验的不足或者架构师的不负责任。以上分别从外部和内部描述了

2016-09-14 11:09:34 1371

转载建议153：若抛出异常，则必须要注释

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

2016-09-14 11:09:27 650

转载建议152：最少，甚至是不要注释

建议152：最少，甚至是不要注释以往，我们在代码中不写上几行注释，就会被认为是钟不负责任的态度。现在，这种观点正在改变。试想，如果我们所有的命名全部采用有意义的单词或词组，注释还有多少存在的价值。即便再详细的注释也不能优化糟糕的代码。并且注释往往不会随着代码的重构自动更新，有时候我们可能会在修改代码后忘记更新那段用来表达最初意图的文字了。所以，尽量抛弃注释吧，除非我们觉得只有良好的

2016-09-14 11:09:07 338

转载建议151：使用事件访问器替换公开的事件成员变量

建议151：使用事件访问器替换公开的事件成员变量事件访问器包含两部分内容：添加访问器和删除访问器。如果涉及公开的事件字段，应该始终使用事件访问器。代码如下所示： class SampleClass { EventHandlerList events = new EventHandlerList(); public event Eve

2016-09-14 11:09:02 333

转载建议150：使用匿名方法、Lambda表达式代替方法

建议150：使用匿名方法、Lambda表达式代替方法方法体如果过小（如小于3行），专门为此定义一个方法就会显得过于繁琐。比如： static void SampeMethod() { Liststring> list=new Liststring>(){"Mike","Rose","Steve"};

2016-09-14 11:08:44 719

转载建议149：使用表驱动法避免过长的if和switch分支

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

2016-09-14 11:08:20 1222

转载建议148：不重复代码

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

2016-09-14 11:08:10 838

转载建议147：重构多个相关属性为一个类

建议147：重构多个相关属性为一个类若存在多个相关属性，就应该考虑是否将其重构为一个类。查看如下类： class Person { public string Address { get; set; } public string ZipCode { get; set; } public string Mobile

2016-09-14 11:07:43 323

转载建议146：只对外公布必要的操作

建议146：只对外公布必要的操作那些没有必要公开的方法和属性要声明成private。如果需要公开的方法和属性超过9个，在VS默认的设置下，就需要滚屏才能显示在Intellisense中，如图：SampleClass类： View Code如上图所示，Intellisence在可见范围内为我们提示的方法还包括了从Object继承过来的3个方法，在这个例子中

2016-09-14 11:07:31 277

转载建议145：避免过长的方法和过长的类

建议145：避免过长的方法和过长的类如果违反“一个方法只做一件事”及类型的“单一职责原则”，往往会产生过长的方法和过长的类。如果方法过长，意味着可以站在更高的层次上重构出若干更小的方法。以行数作为指标，有人建议一个方法不要超过10行，有人建议不要超过30行。当然，这没有唯一标准。在我看了，一个方法在VS中需要滚屏才能阅读完，那么就肯定有些过长了，必须想办法重构它。对于类型

2016-09-14 11:07:07 418

转载建议144：一个方法只做一件事

建议144：一个方法只做一件事“单一职责原则”（SRP）要求每一个类型只负责一件事情。我们将此概念扩展到方法上，就变成了：一个方法只做一件事。回顾上一建议的代码，LocalInit和RemoteInit方法是两件事情，但是在同一抽象层次上，在类型这个层次对外又可以将其归并为“初始化”这一件事情上。所以，“同一件事”要看抽象所处的地位。转自：《编写高质量代

2016-09-13 11:54:55 918

转载建议143：方法抽象级别应在同一层次

建议143：方法抽象级别应在同一层次看下面代码： class SampleClass { public void Init() { //本地初始化代码1 //本地初始化代码2 RemoteInit(); } void Remot

2016-09-13 11:54:39 1524

转载建议142：总是提供有意义的命名

建议142：总是提供有意义的命名除非有特殊原型，否则永远不要为自己的代码提供无意义的命名。害怕需要过长的命名才能提供足够的意义？不要怕，其实我们更介意的是在代码的时候出现一个iTemp。int i 这样的命名只能出现在循环中（如for循环），除此之外，我们找不到任何理由在代码的其他地方出现这样的无意义命名。例如，以下命名都是良好的典范：

2016-09-13 11:54:17 523

转载建议141：不知道该不该用大括号时，就用

建议141：不知道该不该用大括号时，就用如果if条件语句只有一行语句，要不要使用大括号？答案是：建议使用。一个括号不会增加多少代码，但是却让代码看上去增加了一致性。括号本身只会让代码更具条理性。转自：《编写高质量代码改善C#程序的157个建议》陆敏技

2016-09-13 11:54:00 443

转载建议140：使用默认的访问修饰符

建议140：使用默认的访问修饰符《本人不是很赞同》代码整洁的要求之一，就是尽量减少代码，我们从使用默认的访问修饰符开始。类型成员的修饰符默认是private，即下面的代码： class SampleClass { string name; void SampleMethod(){} }等同于：

2016-09-13 11:53:24 312

转载建议139：事件处理器命名采用组合方式

建议139：事件处理器命名采用组合方式所谓事件处理器，就是实际被委托执行的那个方法。查看如下代码： public MainWindow() { InitializeComponent(); Button button = new Button(); button.Click

2016-09-13 11:45:14 290

转载建议138：事件和委托变量使用动词或形容词短语命名

建议138：事件和委托变量使用动词或形容词短语命名事件和委托使用场景是调用某个方法，只不过这个方法由调用者赋值。这决定了对应的变量应该以动词或形容词短语命名。关于事件和委托变量妥当的命名示例如下： public event RoutedEventHandler Click; public event SizeChangedEventHandl

2016-09-13 11:44:51 541

转载建议137：委托和事件类型应添加上级后缀

建议137：委托和事件类型应添加上级后缀委托类型本身是一个类，考虑让派生类的名字以基类名字作为后缀。事件类型是一类特殊的委托，所以事件类型也遵循本建议。委托和事件的正确的命名方式有： public delegate void HttpContinueDelegate(int statusCode, System.Net.WebHeaderCollection ht

2016-09-13 11:44:28 389

转载建议136：优先使用后缀表示已有类型的新版本

建议136：优先使用后缀表示已有类型的新版本加后缀在某些情况下是很奇怪的形式，我们都不愿意看到OrderProcessor2这样的类型。但是，有的时候仍旧有必要这样做。最典型的是FCL中关于数字证书操作的X509Certificate和X509Certificate2这两个类型。 X509Certificate类型最早出现在FCL 1.0/1.1版本中，后来在FCL2.0版本中出

2016-09-13 11:44:13 350

转载建议135：考虑使用肯定性的短语命名布尔属性

建议135：考虑使用肯定性的短语命名布尔属性布尔值无非就是True和False，所以应该用肯定性的短语来表示它，例如，以Is、Can、Has作为前缀。布尔属性正确命名的一个示例如下： class SampleClass { public bool IsEnabled { get; set; } public bool Is

2016-09-13 11:43:57 672

原创 MVC实现伪静态

1 什么是伪静态？现在很多门户网站或者各大电商平台的网站的链接最后都是.htm或者.htm结尾，那么他们的网页真的是静态的html吗？拿京东来说，有无数个页面都都Html，在商品每时每刻都可能被更新的情况下，那是不是要有专门的人员来修改html静态页面呢，可想而知当然不是，不管是javaweb还是asp.net的动态页面绝对不是以.html结尾的。2 为什么要实现伪静态？那么我们为什

2016-09-13 11:42:46 4006

转载建议134：有条件地使用前缀

建议134：有条件地使用前缀在.NET的设计规范中，不建议使用前缀。但是，即便是微软自己依然广泛的使用这前缀。最典型的前缀是m_，这种命名一方面是考虑到历史沿革中的习惯问题，另一方面也许我们确实有必要这么做。在一个不是很庞大的类型中，我们确实不应该使用任何前缀。各类设计规范也总建议我们保持一个娇小的类型，但是往往事与愿违，大类型常常存在。以Task为例，它有2000多行代

2016-09-12 10:59:17 407

转载建议133：用camelCasing命名私有字段和局部变量

建议133：用camelCasing命名私有字段和局部变量私有变量和局部变量只对本类型负责，它们在命名方式也采用和开放的属性及字段不同的方法。camelCasing很适合这类命名。camelCasing和PascalCasing的区别是它的首字母是小写的。之所以要采用这两种不同的命名规则，是为了便于开发者自己快速地区分它们。例如： class Person

2016-09-12 10:59:11 545

转载建议132：考虑用类名作为属性名

建议132：考虑用类名作为属性名一般来说，若果属性对应一个类型，应该直接用类型名命名属性名。如下： class Person { public Company Company { get; set; } } class Company { //省略 }没有必要为属性名指定另外的名字，

2016-09-12 10:59:02 405

转载建议131：用PascalCasing命名公开元素

建议131：用PascalCasing命名公开元素开放给调用者的属性、字段和方法都应该采用PascalCasing命名方法，比如： class Person { public string FirstName; public string LastName; public string Name {

2016-09-12 10:58:50 517

转载建议130：以复数命名枚举类型，以单数命名枚举元素

建议130：以复数命名枚举类型，以单数命名枚举元素枚举类型应该具有负数形式，它表达的是将一组相关元素组合起来的语义。比如： enum Week { Monday, Tuesday, Wednesday, Thursday, Friday, Saturday,

2016-09-12 10:58:37 911

转载建议129：泛型类型参数要以T作为前缀

建议129：泛型类型参数要以T作为前缀作为一种约定，泛型类型的参数要以T作为前缀。如委托声明：Action其中，泛型类型参数名不应该处理成：Action当然，这仅仅是一种习惯，若果使用第二种命名方式，编译器并不会报错，但是作为调用者，也许不能意识到这里是一个泛型类型参数。这个问题在为类型指定泛型的时候尤为明显，因为为类型指定泛型类型参数的声明不会出现在公开的

2016-09-12 10:58:24 1048

转载建议128：考虑让派生类的名字以基类名字作为后缀

建议128：考虑让派生类的名字以基类名字作为后缀派生类的名字可以考虑以基类名字作为后缀。这带来的好处是，从类型的名字上我们就知道它包含在哪一个继承体系中。Exception及其子类就是这样一个典型的例子。所有的异常都应该继承自System.Exception，而所有的异常都应该命名为CustomedException。如果在VS中输入Exception，再按Tab键，会自动生成如下

2016-09-12 10:58:14 675

转载建议127：用形容词组给接口命名

建议127：用形容词组给接口命名接口规范的是“Can do”，也就是说，它规范的是类型可以具有哪些行为。所以，接口的命名应该是一个形容词，如：IDisposable表示可以被释放IEnumerable表示类型含有Items，可以被迭代。正是因为接口表示的是类型的行为，所以从语义上可以让类型继承多个接口，如： class SampleClass :

2016-09-12 10:58:07 1454

转载建议126：用名词和名词组给类型命名

建议126：用名词和名词组给类型命名类型对应着现实世界中的实际对象。对象在语言中意味着它是一个名词。所以，类型也应该以名词或名词词组去命名。类型定义了属性和行为。虽然它包含行为，但不是行为本身。所以，下面的一些命名对于类型来说是好的命名：OrderProcessorScoreManagerCourseRepositoryUserControl

2016-09-12 10:57:56 328

转载建议125：避免用FCL的类型名称命名自己的类型

建议125：避免用FCL的类型名称命名自己的类型试想过自己写一个Socket类型吗？如果没有，我们来尝试一下：public class Socket{ //省略 }把以上代码同某些其他工具类封装到某个dll里，让其他人调用。调用者代码如下：public class SampleInvoker{ public void DoSomethin

2016-09-12 10:57:48 366

转载建议124：考虑在命名空间中使用复数

建议124：考虑在命名空间中使用复数如果有一组功能相近的类型被分到了同一个命名空间下，可以考虑为命名空间使用复数。最典型的例子有，在FCL中，我们需要把所有的非泛型集合类集中在一起存放，所以就有了System.Collections命名空间。这样的命名规范，好处是即便没有使用过集合类的人，看到这个命名空间，也会知道它之下是和集合（即Collection）相关的一些类型。不要出现类似

2016-09-12 10:57:37 508

转载建议123：程序集不必与命名空间同名

建议123：程序集不必与命名空间同名程序集一般会和命名空间同名，但这并不是必须的。事实上，不同名的命名空间和程序集是很常见的。程序集表示的是一种物理上的分组，而命名空间是逻辑上的分组，两者没有必然联系。当然，如果项目最终会被编译为dll，则我们更建议程序集和命名空间命名保持一致，这看上去更符合习惯。比如System.Data命名空间，对应的应该有一个System.Data.

2016-09-12 10:57:31 401

转载建议122：以<Company>.<Component>为命名空间命名

建议122：以.为命名空间命名建议以.为程序集命名，比如Microsoft.Windows.Design。这有助于唯一地标识我们的命名空间。另外一种有效且肯定是唯一的表示命名空间的方式是使用域名。假设我们的域名是www.microsoft.com，那么命名空间应该命名为Com.Microsoft.。使用域名命名自己的程序的方法在Java世界中一直很流行，现在不妨把这种习惯带到.NE

2016-09-12 10:57:22 439

转载建议121：为应用程序设定运行权限

建议121：为应用程序设定运行权限在某些情况下，可能存在这样的需求：只有系统管理员才能访问某应用程序的若干功能。这个时候，可以结合.NET中提供的代码访问安全性（Code Access Security）和基于角色（Role-Based Security）的安全性去实现。如果要通过一下的代码正常的访问类型SampleClass，用户必须以Administrator的身份运行代码：

2016-09-12 10:57:13 512

转载建议120：为程序集指定强名称

建议120：为程序集指定强名称虽然强名称在设计之初有防止被未授权的第三方软件非法执行程序的作用，但是因为它的破解方法并不难，所以现在强名称更多的意义在于它可以避免出现“DLL HELL”现象。 “DLL HELL”是指多个应用程序可能调用同一个DLL的情况。在应用程序使用过程中，常常会碰到这样一种情况：应用程序需要更新。在更新过程中，很有可能将会和别的应用程序公用的DLL也更新了。

2016-09-12 10:57:06 345

转载建议119：不要使用自己的加密算法

建议119：不要使用自己的加密算法很多人认为自己写的加密算法才是安全的，因为该算法只有“自己知道”。很遗憾，这是大错特错。首先，我们不是秘密学专家，如果我们随随便便写个算法就称得上是加密算法的话，那么世界上就不会存在“密码学”这个专门的学科了。其次，应当记住的是：让数据安全的不是加密算法本身，而是密钥。当今世界上有许多流行的加密算法都是公开源码和逻辑的，如DES、A

2016-09-12 10:56:59 2661

空空如也

空空如也