发布新日志

  • FxCop 设计规则

    2010-05-25 12:05:14

    一、 Design(设计)
    1. Abstract types should not have constructors
    抽象类不应该声明构造方法

    2. Assemblies should have valid strong names
    程序集应该具有强名称

    3. Avoid empty interfaces
    避免使用空的接口

    4. Avoid excessive parameters on generic types
    避免在泛型类中使用过多的类型参数

    5. Avoid namespaces with few types
    避免让名字空间含有过少的类型

    6. Avoid out parameters
    避免使用 out类型的参数

    7. Collections should implement generic interface
    集合类应该实现泛型接口

    8. Consider passing base types as parameters
    尽量使用基本类型作为参数

    9. Declare event handlers correctly
    正确的声明事件处理器,事件处理器不应该具有返回值

    10. Declare types in namespaces
    应该在名字空间里面定义类型,而不是外面

    11. Default parameters should not be used
    不应该使用参数默认值(C#没有参数默认值)

    12. Define accessors for attribute arguments
    应该为特性(特性)的构造方法参数定义访问器,其名字跟构造方法参数仅首字母大小写不一样

    13. Do not catch general exception types
    不要捕捉普通的异常(即System.Exception

    14. Do not declare protected members in sealed types
    不要在封闭类型中定义受保护的成员

    15. Do not declare static members on generic types
    不要在泛型类型中使用静态成员

    16. Do not declare virtual members in sealed types
    不要在封闭类型中定义虚成员

    17. Do not declare visible instance fields
    不要定义可见的(public/internal)实例域变量

    18. Do not expose generic lists
    不要直接暴露范型表

    19. Do not hide base class methods
    不要隐藏(使用或者不使用new)基类的方法

    20. Do not nest generic types in member signatures
    不要在成员的签名(参数或者返回值)中嵌套泛型类

    21. Do not override operator equals on reference types
    不要在引用类型中重载==操作符

    22. Do not pass types by reference
    不要使用引用(ref or out)传递类型

    23. Enum Storage should be Int32
    枚举应该是 Int32 类型的

    24. Enumerators should be strongly typed
    枚举器应该是强类型的

    25. Enums should have zero value
    枚举应该具有0

    26. Generic methods should provide type parameter
    泛型类的方法应该提供类型参数

    27. ICollection implementations have strongly typed members
    集合接口的实现中应该使用强类型的成员

    28. Implement standard exception constructors
    自定义的异常应该实现异常类的四个标准构造方法

    29. Indexers should not be multidimensional
    索引不应该是多维的

    30. Interface methods should be callable by child types
    接口方法应该可以被子类调用

    31. Lists are strongly typed
    表应该是强类型的

    32. Mark assemblies with assembly version
    用程序集版本标示程序集

    33. Mark assemblies with CLSCompliant
    使用CLSCompliant特性标示程序集

    34. Mark assemblies with ComVisible
    使用 System.Runtime.InteropServices.ComVisibleAttribute 特性标示程序集

    35. Mark attributes with AttributeUsageAttribute
    使用 AttributeUsageAttribute 特性标示特性类

    36. Mark enums with FlagsAttribute
    含有组合的枚举应该使用FlagsAttribute特性标示,相反则不应该

    37. Members should not expose certain concrete types
    成员(返回值或者参数)不应该暴露具体类型,尽量使用接口

    38. Move pinvokes to native methods class
    将调用移到本地方法类(不是很理解)

    39. Nested types should not be visible
    嵌套类型不应该是可见的

    40. Override methods on comparable types
    可比较类型应该重写 equals 等方法

    41. Override operator equals on overriding add and subtract
    在重写+-运算的时候应该同时重写==操作符

    42. Properties should not be write only
    属性不应该是只写的

    43. Provide ObsoleteAttribute message
    过时的成员应该使用ObsoleteAttribute特性标示,并提供相应的Message提示使用者

    44. Replace repetitive arguments with params array
    使用参数数组代替重复的参数

    45. Static holder types should be sealed
    仅含有静态成员的类型应该声明为封闭的

    46. Static holder types should not have constructors
    仅含有静态成员的类型应该具有构造方法

    47. String uri overloads call system uri overloads
    使用string类型的uri参数的重载应调用系统的使用URI类型参数的重载

    48. Types should not extend certain base types
    类型不应该从具体的类(已经过派生的类)继承,比如异常类不应该从ApplicationException继承,而应该从System.Exception继承

    49. Types that own disposable fields should be disposable
    含有可释放成员的类型应该是可以释放的(实现IDisposable接口)

    50. Types that own native resources should be disposable
    使用了非托管资源的类型应该是可以释放的(实现IDisposable接口)

    51. Uri parameters should not be strings
    Uri
    参数不应该是string类型的

    52. Uri properties should not be strings
    Uri
    属性不应该是string类型的

    53. Uri return values should not be strings
    Uri
    类型的返回值不应该是string类型的

    54. Use events where appropriate
    在适当的时候使用事件

    55. Use generic event handler instances
    使用泛型的事件处理器实例

    56. Use generics where appropriate
    在适当的时候使用范型

    57. Use integral or string argument for indexers
    索引器应该使用整数或者字符串类型的参数

    58. Use properties where appropriate
    在适当的时候使用属性(而不是以Get或者Set开头的方法)

    59. Validate arguments of public methods
    public的方法的参数应该在方法开头处进行检验(比如是否为null的检验)

    二、 Globalization(全球化)
    1. Avoid duplicate accelerators
    避免在顶层控件中使用重复的快捷键(加速键)
    2. Do not hardcode locale specific strings
    不要对本地的特殊字符串(比如特殊的系统路径)进行硬编码

    3. Do not pass literals as localized parameters
    不要把文本作为需要本地化的参数直接传递(尽量使用资源文件)

    4. Set locale for data types
    为某些数据类型设定区域和语言属性(DataSetDataTablelocale属性)

    <P class=MsoNormal style="MARGIN: 9pt 0cm
  • 适用于 .NET 的静态分析工具

    2010-05-25 11:55:52

    http://msdn.microsoft.com/zh-cn/magazine/dd263071.aspx

    使用静态代码分析工具提高软件质量
    许多软件团队使用代码评审来确保开发人员编写的代码正确、安全且符合公司的设计原则。这些原则可能规定了访问数据或其他外部资源所使用的命名约定、模式等内容。代码评审过程的很多方面都很机械,因此可以自动执行。静态代码分析工具扫描源代码或中间代码,并搜索违反定义的设计原则规则的代码。
    FxCop (1.36 版)就是这样一个针对 Microsoft .NET Framework 中的应用程序的静态分析工具,由 Microsoft 创建,免费提供。FxCop 分析编译的 .NET 程序集的中间代码,并提供相关的建议来改进设计、安全性和性能。默认情况下,FxCop 根据开发类库的设计原则设定的规则分析程序集。设计原则规则可划分为九个类别,其中包括设计、全球化、性能和安全性等内容。例如,其中一个命名规则是“事件不能使用‘before’或‘after’前缀”。如果 FxCop 识别出某事件的名称为 BeforeUpdate,它便会建议您将 BeforeUpdate 替换为事件名称的现在时形式,即 Update。您也可以插入自定义规则类来反映您公司的内部设计原则。
    要分析程序集,先启动 FxCop,创建新的项目,然后将程序集添加到该项目。FxCop 会显示分析该程序集时使用的 200 多个规则;您可以关闭现有的规则或添加您自己的规则。单击“分析”按钮开始分析。在枚举出该程序集的类型、类、方法和成员后,FxCop 会显示分析结果,其中将列出违反规则的代码和其所违反的规则。选择一项结果可以查看更加详细的描述和解决方案。
    FxCop 作为独立的应用程序提供,还包含命令行实现功能,用户可轻松将其插入到自动执行的构建过程中。(代码分析是一项与 FxCop 非常相似的工具,附带 Visual Studio Team System,并已集成到 Visual Studio Shell 中。)有关如何使用 FxCop 的详细信息,请参阅 John Robbins 撰写的 Bugslayer 专栏:“遇到糟糕代码?FxCop 相助”和“三个重要的 FXCop 规则。”
    FxCop 根据 .NET 设计原则设定的规则分析程序集(单击图像可查看大图)
    Microsoft 还提供了一个静态代码分析工具,即 StyleCop (4.3 版)。FxCop 评估中间代码是否符合设计原则,而 StyleCop 评估的对象是 C# 源代码的样式。样式原则是指定应该如何对源代码进行格式化的规则,规定是否应该在 for 循环、if 语句和其他结构的缩进和格式中使用空格和制表符。StyleCop 示例规则包括:for 语句的主体应括在一对大括号中;= 和 != 运算符两边应有空格;对类内部成员变量的调用必须以“this”开头。
    StyleCop 没有集成到 Visual Studio Team System 中,您必须亲自安装。在 Visual Studio 中执行 StyleCop 会分析当前打开的解决方案中的源代码,并在错误列表窗口中以警告的形式显示结果。StyleCop 也可以与 MSBuild 集成。
    当 FxCop 和 StyleCop 查明违反规则的代码时,开发人员仍负责实现这些工具的建议。SubMain 的 CodeIt.Right(1.1 版)通过使违反规则的代码自动重构为一致的代码,将静态代码分析提升到了一个更高的级别。与 FxCop 类似,CodeIt.Right 也附带一组丰富的预定义规则(如前面提到的设计原则文档所述),能够添加自定义规则,但 CodeIt.Right 使创建和使用自定义规则更加轻松。
    使用 FxCop 中的自定义规则需要构建和编译规则类并将其插入 FxCop。使用 CodeIt.Right,会从图形用户界面生成自定义规则;定义新规则需要采用基本行为模式,然后自定义一些属性。CodeIt.Right 集成了 Visual Studio .NET 2003、Visual Studio 2005 和 Visual Studio 2008 的解释器,还提供了命令行实现功能。
    CodeIt.Right 更新所选的违反规则的代码,使之符合规则(单击图像可查看大图)
    要在 Visual Studio 中使用 CodeIt.Right,请在 CodeIt.Right 菜单中选择“开始分析”选项。分析完解决方案后,CodeIt.Right 在 Visual Studio IDE 的窗口中显示结果,其中将列出每个违反规则的代码。此报表可以导出为 XML 文件,也可以导出为 Microsoft Office Excel 文件。
    CodeIt.Right 最大的优点是自动代码重构功能。您可以通过结果屏幕查看需要修复哪些违反规则的代码,然后单击“修复选中项”(Correct Checked) 按钮。CodeIt.Right 所做的所有更改都会在 Visual Studio 中突出显示,单击一个按钮即可将自动进行的更改恢复到原来状态。
    静态代码分析工具提供了一种快速、自动化的方法,来确保您的源代码符合预定义的设计和样式原则。遵循这些原则有助于生成更统一的代码,还可以查出潜在的安全性、性能、互操作性和全球化方面的缺陷。静态代码分析工具不能代替人为代码评审,但是,它们可以先检查一遍代码库,并突出显示需要高级开发人员特别注意的地方。
    价格:FxCop(免费);StyleCop(免费);CodeIt.Right(每个用户许可证 250 美元)。
Open Toolbar