强制编码风格是一个长期被热烈争论的话题。人们不仅为团队应该遵循何种编码风格而争论不休,同时还要争论究竟是否应该确立一个标准的编码风格。现在,微软发布了StyleCop,这是他们在内部使用的一个编码风格强制工具,微软的这一举措无疑将起到推波助澜的作用。
StyleCop,也即所谓的 微软C#源代码分析器(Microsoft Source Analysis for C#),用途和FxCop相似,只不过作用对象是源代码。此外,它和FxCop一样是源于微软的内部工具,在发展到一定程度之后,微软觉得对其他人也有 用,于是被公开发布。不过,StyleCop的自定义程度不如FxCop那么高。
StyleCop,也即所谓的 微软C#源代码分析器(Microsoft Source Analysis for C#),用途和FxCop相似,只不过作用对象是源代码。此外,它和FxCop一样是源于微软的内部工具,在发展到一定程度之后,微软觉得对其他人也有 用,于是被公开发布。不过,StyleCop的自定义程度不如FxCop那么高。
Jason Allor声称由这个工具所强制要求的大约200条规则与Visual Studio的默认设置是兼容的。遗憾的是,他忘记提到Visual Studio具有6个完全不同的默认设置集合,其中多数与这个工具互相矛盾的。
这个工具涉及的方面包括:
- 支持文件内容
- 调试文本
- 编排元素头和文件头中的文档格式
- 元素、语句、表达式和查询子句的布局
- 行空格
- 元素、字段和变量的命名
- 大括号、圆括号、方括号等的位置
- 在方法声明或方法调用中方法参数的位置
- 关键字和操作符周围的空格
- 在类中元素的标准顺序
- 访问修饰符的使用
- 内置类型的使用
在空白的控制台应用程序上运行这些规则,会返回9个错误,如果你打开“Keep Tabs”设置,则会出现16个错误。一些规则稍显笨拙,例如要求“using”指示符必须放在命名空间内,而不是放在文件顶部。
已经有人在抱怨这个工具缺乏校正的支持。Dustin Norman写道:
在将这个工具运行在一个较小的程序集上时,这个工具要我手动修改561个违规错误,而它却不能在不影响代码语义的基础上自动为我修复错误——这真的要让我崩溃了!
古老的tabs vs spaces争论【译者注:即代码的缩进是用Tabs来实现还是用Spaces来实现】又被提及,而且我们还不能禁用这一规则。Nick Berardi写道:
真是开玩笑。Tabs居然不被允许。相反,只能使用空格。这个主意糟透了,因为它会破坏语句块的布局,例如一个变量使用3个空格,而其他变量则使用了4个。无论如何,应该允许禁用类似tab规则这样毫无意义的规则。
如 果能够禁用这些规则,这个工具就更好了。我知道你会说他们已经够好了。但是我完全不同意使用空格来代替tab。这是毫无逻辑可言的,或许只有在Vi编辑器 第一次出现从而引发了开发人员之间的“圣战”可堪比拟吧。我喜欢用Tab的方式编写我的代码,但它总是警告我,我的每行代码都有tab在其中。
同时,Daniel Stolt也问到了关于VB的情况:为.NET开发人员提供一些额外工具总是受欢迎的——但为什么只有C#的?代码格式的强制规则对于VB开发人员来说也是非常需要的。
显然,VB代码编辑器在对关键字和操作符进行缩进和空格的处理中,已经具有自动格式化的一些初步支持,但还不够接近StyleCop所支持的效果。
顺便说来,我完全同意Nick Berardi对于tabs vs spaces的观点:使用tabs有什么问题?难道按4-5次方向按钮比直接指向某个位置更有某种优势?还是在源代码文件中保存4-5个空白字符存在着某种好处?
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/12639172/viewspace-364684/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/12639172/viewspace-364684/