3 回答
TA贡献1777条经验 获得超10个赞
具有讽刺意味的是,设置实际标准可能很容易。
我的第一个建议是从其他工程师那里获得关于他们应该涵盖的内容以及他们认为重要的准则的建议。实施任何类型的指南都需要一定程度的人员支持。如果您突然在文档上放了一个文档,该文档指定了如何编写代码,那么无论您是最初级的还是高级的,您都会遇到阻力。
提出一组建议后,请将其发送给团队以征询反馈并进行审查。再一次,让人们全力以赴。
可能已经采用了非正式的编码实践(例如,为成员变量加上前缀,驼峰函数名称)。如果存在,并且大多数代码都遵循它,那么它将需要形式化其使用。即使通常建议这样做,采用相反的标准也会引起更多的痛苦。
还值得考虑重构现有代码以满足新的编码标准。这看起来似乎是在浪费时间,但是拥有不符合标准的代码可能会适得其反,因为您将遇到各种风格的混搭。人们是否在某个模块中的代码应该遵循新标准还是遵循现有代码风格方面也陷入了困境。
TA贡献1780条经验 获得超5个赞
切勿使用MS(或适用于您的语言的Sun或...)编写自己的编码标准。线索在“标准”一词中,如果每个组织都没有决定自己编写代码,那么世界将更容易编码。谁真的认为每次您更改团队/项目/角色时学习一套新的“标准”都是对任何人的时间的良好利用。您应该做的最大的事情就是总结关键点,但是我建议不要这样做,因为关键的内容因人而异。我想就编码标准提出另外两点
闭合足够好-只要代码足够接近,更改代码以遵循字母的编码标准是浪费时间。
如果要更改代码,则不会遵循“本地编码标准”来编写代码,即使新代码看起来像周围的代码。
这两点是我希望每个人都编写看起来相同的代码的现实。
- 3 回答
- 0 关注
- 329 浏览
添加回答
举报