对于开发C#编码标准/最佳实践文档有什么建议吗?
我是AI毕业生(大约2年),正在做一个适度的手术。我已经(主要是因为我是该部门中的第一个"采用者")来创建一个基本的(了解有用吗?)编码标准文档。
我想我应该解释一下,我可能是最初级的软件工程师,但是我很期待这个任务,因为我希望实际上可以产生一半可用的东西。我已经在Internet上进行了相当广泛的搜索,并阅读了有关编码标准文档应包含/不应包含的文章。这似乎是任何寻求一些建议的好地方。
我意识到,我有可能为关于"最好的做事方式"的整个世界打开一扇门。我既理解又尊重一个不可否认的事实,即每个程序员都有解决每个任务的首选方法,因此,我不是想写任何过于pro脚的命令来扼杀个人才能,而是尝试获得一种通用方法并达成共识标准(例如命名约定),以帮助使个人代码更具可读性。
所以这里....有什么建议吗?有没有
解决方案
回答
微软自己的规则是一个很好的起点。我们可以使用FxCop实施它们。
回答
我们从
- Microsoft的.NET指南:http://msdn.microsoft.com/zh-cn/library/ms229042.aspx(针对.NET 4.5更新的链接)
- Microsoft的C#准则:http://blogs.msdn.com/brada/articles/361363.aspx。
然后记录与该基准的区别和补充。
回答
在内部进行编码标准/最佳实践时,我一直使用Juval Lowy的pdf作为参考。它非常接近FxCop / Source Analysis,它是确保遵循标准的另一个宝贵工具。在这些工具和参考之间,我们应该能够提出一个好的标准,所有开发人员都不会介意并能够执行它们。
回答
IDesign具有一个常用的Ccoding标准文档。另请参阅《框架设计指南》第二版。
回答
其他海报指出我们是基线,我要补充的是使文档简短,甜美,并且要点,要使用大量的Strunk和White来区分"必须拥有的"和"如果有的话最好"。 "。
编码标准文档的问题在于,没有人真正按照需要阅读它们,而当他们阅读它们时,他们就不会遵循它们。读取和跟踪此类文档的可能性与其长度成反比。
我同意FxCop是一个很好的工具,但是太多的东西可能会使编程失去所有乐趣,因此请小心。
回答
具有讽刺意味的是,设置实际标准可能很容易。
我的第一个建议是从其他工程师那里获得关于他们应该涵盖的内容以及他们认为重要的准则的建议。实施任何类型的指南都需要一定程度的人员支持。如果我们突然在文档上放了一个文档,该文档指定了如何编写代码,则无论我们是最初级的还是高级的,都会遇到阻力。
在我们获得一组建议之后,请将其发送给团队以征询反馈并进行审查。再一次,让人们全力以赴。
可能已经采用了非正式的编码实践(例如,为成员变量加上前缀,驼峰函数名称)。如果存在,并且大多数代码都遵循它,那么它将花钱使它的使用正式化。即使通常建议这样做,采用相反的标准也会带来更多的痛苦。
还值得考虑重构现有代码以满足新的编码标准。这看起来像是在浪费时间,但是拥有不符合标准的代码可能会适得其反,因为我们将遇到各种风格的混搭。人们是否在某个模块中的代码应该遵循新标准还是遵循现有代码风格方面也陷入了困境。
回答
我想在此回应其他评论,即已经链接的MS准则是一个很好的起点。我主要在这些代码上建模。
这很有趣,因为我的经理过去告诉我他不太热衷于他们:D
我的朋友,我们面前的工作很有趣。祝我们好运,请询问我们是否还需要其他:)
回答
You are most likely being set up to fail. Welcome to the industry.
我不同意,只要他创建该文档,最糟糕的事情就是每个人都会忘记它。
如果其他人对内容有疑问,则可以要求他们进行更新以显示他们的喜好。这样一来,我们就可以摆脱困境,其他人有责任证明自己的更改合理。
回答
切勿使用MS(或者适用于语言的Sun或者...)编写自己的编码标准。线索在"标准"一词中,如果每个组织都没有决定自己编写代码,那么世界将更容易编码。谁真的认为每次我们更改团队/项目/角色时学习一套新的"标准"都是对任何人的时间的良好利用。
我们应该做的最大的事情就是总结关键点,但是我建议不要这样做,因为关键的内容因人而异。
我想就编码标准提出另外两点
- 闭合足够好-只要代码足够接近,更改代码以遵循字母的编码标准是浪费时间。
- 如果我们要更改代码,则不会遵循"本地编码标准"来编写代码,即使新代码看起来像周围的代码。
这两点是我希望每个人都编写看起来相同的代码的现实。
回答
飞利浦医疗系统公司的标准写得很好,并且主要遵循Microsoft准则:www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf
我的标准基于此进行了一些调整,并且对.NET 2.0进行了一些更新(飞利浦标准是为.NET 1.x编写的,因此有点过时了)。
回答
我很想强制执行Microsoft的StyleCop作为标准。可以在构建时强制执行。但是,如果我们有旧版代码,则只需对新代码强制使用StyleCop。
http://code.msdn.microsoft.com/sourceanalysis
最终它将有一个重构选项来清理代码。
http://blogs.msdn.com/sourceanalysis/
回答
我会将"代码完成2"添加到列表中(我知道Jeff在这里很喜欢)...如果我们是初级开发人员,那么这本书就很容易设定想法,从而为最好的基础有代码编写实践和软件构建。
我不得不说我在职业生涯中来得有点晚,但是它决定了我在职业生涯中对编码和框架开发的许多思考方式。
值得一试;)
回答
我最近找到了Encodo CHandbook,其中包含来自许多其他来源(IDesign,Philips,MSDN)的想法。
另一个来源可能是"专业C#/ VB .NET编码准则"。
回答
我发现以下文档非常有用和简洁。它来自idesign.net网站,由Juval Lowy创作
编码标准
注意:以上链接现已消失。要获取.zip文件,我们需要向他们提供电子邮件地址(但老实说,他们不会将其用于市场营销...)
回答
我是Francesco Balena的著作《 VB和CDeveloper的实践准则和最佳实践》的忠实拥护者。
它非常详细,涵盖了所有基本主题。它不仅为我们提供了规则,而且还解释了该规则背后的原因,甚至提供了可能存在两个相反最佳实践的反规则。唯一的缺点是它是为.NET 1.1开发人员编写的。
回答
看到这个:
http://www.noesispedia.com/post/2008/11/28/C-Coding-Guidelines-and-Best-Practices.aspx。
回答
我刚开始在一个地方,编码标准要求对成员变量使用m_,对参数使用p_,对类型使用前缀,例如对字符串使用'str'。
因此,方法主体中可能会有类似以下内容:
m_strName = p_strName;
可怕。真可怕。
回答
我个人很喜欢IDesign组装的产品。但这不是我要发布的原因...
我公司的棘手问题是考虑了所有不同的语言。我知道我的公司并不孤单。我们使用C#,C,程序集(我们制造设备),SQL,XAML等。尽管标准中会有一些相似之处,但是每种标准的处理方式通常都是不同的。
另外,我相信更高级别的标准对最终产品的质量会有更大的影响。例如:如何以及何时使用注释,何时强制使用异常(例如,用户启动的事件),是否(或者何时)使用异常与返回值,什么是确定控制器代码与表示代码应采用的客观方法,等。不要误会我的意思,也需要低级别的标准(格式对于可读性很重要!)我只是偏向于整体结构。
另一个需要牢记的是买入和强制执行。编码标准很棒。但是,如果没有人同意他们,并且(可能更重要的是)没有人强迫他们,那一切都是徒劳的。
回答
我们的整个编码标准的内容大致为"使用StyleCop"。
回答
我必须建议dotnetspider.com文件。
这是一个非常详尽的文档,可在任何地方使用。