我是最近的AI毕业生(大约2年),从事适度的操作.它已经落到我身上(主要是因为我是该部门的第一个"采用者")来创建一个基本的(阅读有用的？)C#编码标准文档.
我想我应该解释一下,我可能是最初级的软件工程师,但我期待着这项任务,希望我实际上可以生产出一半可用的东西.我已经对互联网进行了大量的搜索,并阅读了有关编码标准文档应该/不应该包含的内容的文章.这似乎是一个很好的地方,可以提出一些建议.
我意识到,我可能会打开一扇门,通往一个关于"最好的做事方式"的分歧.我既理解又尊重不可否认的事实,即每个程序员都有一个解决每个任务的首选方法,因此我不打算写任何如此严厉的禁止,以至于扼杀个人风格,而是试图获得一般方法并达成一致标准(例如命名约定),以帮助使个人代码更具可读性.
所以这里......任何建议？有没有？
我们一开始
Microsoft的.NET准则:http://msdn.microsoft.com/en-us/library/ms229042.aspx(针对.NET 4.5更新的链接)
微软的C#指南:http://blogs.msdn.com/brada/articles/361363.aspx.
然后记录该基线的差异和增加.
IDesign有一个常用的C#编码标准文档.另请参阅框架设计指南第二版.
具有讽刺意味的是,设定实际标准可能很容易.
我的第一个建议是引出其他工程师关于他们认为应该涵盖的内容的建议,以及他们认为重要的指导方针.执行任何类型的指导都需要人们的一定程度的支持.如果你突然放下一个指定如何编写代码的文档,你会遇到阻力,无论你是最初级的还是高级的.
在您有一组提案后,将它们发送给团队以获得反馈和审核.再一次,让所有人都购买它们.
可能已经采用了非正式编码实践(例如,为成员变量添加前缀,使用camelcase函数名称).如果存在,并且大多数代码符合它,那么它将支付正式使用它.采用相反的标准会导致更多的悲伤而不是它的价值,即使它是一般推荐的东西.
同样值得考虑重构现有代码以满足新的编码标准.这似乎是浪费时间,但是如果代码不符合标准可能会适得其反,因为您将拥有不同风格的混搭.它还使人们陷入两难境地,即某个模块中的代码是否应符合新标准或遵循现有的代码风格.
在内部编写标准/最佳实践时,我一直使用Juval Lowy的pdf作为参考.它非常接近FxCop/Source Analysis,这是另一个确保遵循标准的宝贵工具.在这些工具和引用之间,您应该能够提出一个很好的标准,所有开发人员都不会关注它并能够强制执行它们.
其他海报已经指出你的基线,所有我想补充的是让你的文件简短,甜美,并且重点,使用大剂量的Strunk和White来区分"必须有的"和"这将是很好的ifs ".
编码标准文档的问题在于没有人真正按照他们的意愿阅读它们,当他们阅读它们时,他们不会遵循它们.阅读和遵循此类文档的可能性与其长度成反比.
我同意FxCop是一个很好的工具,但是太多的东西可以带来编程的所有乐趣,所以要小心.
永远不要使用MS编写自己的编码标准(或者根据您的语言编写Sun版本或......).线索是标准一词,如果每个组织都没有决定自己编写,那么世界将是一个更容易编码的地方.每当你改变团队/项目/角色时,谁真的认为学习一套新的"标准"是一个很好的利用任何人的时间.你应该做的最多的是总结关键点,但我建议不要这样做,因为关键点因人而异.我想对编码标准提出另外两点
关闭已经足够了 - 只要代码足够接近,更改代码以遵循编码标准就会浪费时间.
如果您要更改代码,则不要按照"本地编码标准"进行编写,即使新代码看起来像周围的代码.
这两点是我希望每个人都能编写看起来相同的代码的现实.
我发现以下文档非常有用和简洁.它来自idesign.net网站,由Juval Lowy撰写
C#编码标准
注意:上面的链接已经死了.要获取.zip文件,您需要向他们提供您的电子邮件地址(但他们不会将其用于营销...老实说)在此尝试
我会将Code Complete 2添加到列表中(我知道Jeff在这里是一个粉丝)...如果你是一名初级开发人员,那么这本书就可以用来为最好的基础奠定基础.代码编写实践和软件构建.
我不得不说我的职业生涯有点晚了,但它决定了我在职业生涯中对编码和框架开发的许多思考方式.
值得一试;)
我刚刚开始在一个地方,编码标准要求使用m_作为成员变量,p_表示参数和类型的前缀,例如字符串的'str'.所以,你可能在方法的主体中有这样的东西:
m_strName = p_strName;
可怕.真的太可怕了.
京公网安备 11010802040832号 | 京ICP备19059560号-6 