你们有编码标准吗?如果是,它们是如何执行的?

我曾经在一些几乎没有遵循编码实践的地方工作过,而在其他地方,这些实践接近于被实施——或者至少很容易被检查。

• 最重要的是接受一致性胜过个人偏好风格的观点。在制定编码标准之前和之后都应该讨论编码标准,但不允许任何人选择退出。
• 代码审查应该是强制性的,签入注释包括审查者的用户名。如果您使用的是一个适当的强大的SCM,请考虑不允许没有有效的审阅者姓名的签入。
• 应该有一份文件 每个人 知道如何制定编码标准。有了足够的细节,你不应该在争论的过程中得到太多。
• 在可能的情况下,自动检查约定(通过Lint、CheckStyle、FXCop等),这样提交者和审阅者都可以轻松地快速检查诸如命令导入/使用指令、空格等内容。

好处是:

• 主要是一致性——如果您能够让任何人在任何时候都能在代码库的任何部分感到“自在”,那么它将为您提供更大的灵活性。
• 传播最佳实践——如果您禁止公共字段、可变结构等,那么没有人会意外地在代码中植入定时炸弹。(至少,这不是标准所涵盖的定时炸弹。当然,完美的代码没有编码标准:)

编辑:我应该指出,编码标准可能是 在大公司工作时很重要。我相信,即使是在小公司,它们也会有所帮助,但在这一点上,围绕标准的流程需求可能会减少。当所有开发人员都相互认识并且都位于同一地点时,这会有所帮助。

你们有编码标准吗?

它包括什么?

代码(类、变量、方法、常量)、SQL命名和格式约定

是的,项目中的每一个新加入者都可以被要求按照组织编码惯例创建一个演示项目,然后进行评审。这个练习使开发人员在开始真正的工作之前感到轻松。

你会做什么(如果有的话)来确保每个人都遵守标准?

使用StyleCop和FxCop 以确保他们被虔诚地跟随。它将显示为 如果代码不符合要求,则发出警告/错误 具有组织编码约定。

VisualStudio团队系统 有 这将阻止开发人员签入不符合要求的代码

希望有帮助

谢谢 莫迪

我们使用Eclipse的保存操作和格式化程序。我们确实有一个建议的标准,但实际上没有人强制执行它,所以在实际格式化的内容和方式上有一些变化。

这有点讨厌(对我来说),因为各种各样的空格变化都会作为SVN存储库的更新提交。。。

StyleCop 在实施编码布局实践方面做得很好,如果基本规则中没有包含对您很重要的内容,您可以为其编写自定义规则。

我认为编码标准非常重要。没有什么比试图找出一个文件的两个版本之间的差异,却发现整个文件都被重新格式化的人更改了更令人沮丧的了。我知道有人会说这种做法应该取消,但大多数IDE都有一个“重新格式化文件”功能(例如,VisualStudio中的Ctrl-K Ctrl-D),这使得代码的布局更加简单。

我发现最好的编码标准不是团队中某个人制定的标准。我实现了iDesign创建的标准( click here

快速提及代码样式强制器( click here )这对于在VisualStudio中突出显示不合规性非常有用。

我认为可能会有一些尊重或专业的赞美,作为一种让人们遵循编码标准的方式,其中一些部分在应用后变得清晰,例如重构一个函数以提高可读性,或者在某种形式上添加测试,借用奥普拉的一句话,使用各种“灯泡时刻”。

好处的另一部分是了解其他人的工作情况,他们有哪些技巧和技术,以及如何随着时间的推移改进以成为一名更好的开发人员。

• 记录并提供单元测试,以说明使用给定例程或模块的给定接口的所有典型场景。
• 在可能的情况下,使用以下容器类库等。。。
• 使用断言验证传入参数和返回的结果(C&C++)
• 最小化所有变量的范围
• 通过方法访问对象成员
• 在malloc和free上使用new和delete
• 使用指定的命名约定

哦,是的,我是编码标准警察:)我只是写了一个简单的脚本来定期检查和修复代码(我的编码标准是 simple enough 我希望人们在看到所有这些“编码惯例清理”消息后会得到这个消息:)

我们有一种“宽松”的标准。也许是因为我们无法就其中的一些问题达成一致意见,比如“在那里和那里放置多少空格”、“在语句之后或下一行的何处放置我的大括号”。

“坚持主开发人员使用的样式”

所以如果他想做3个空格缩进,你自己也要做。

你们有编码标准吗? 它包括什么?

每个人都在关注它吗?

大多数情况下,获得 团队协议

它是如何执行的?

轻轻地说,我们没有编码标准cop。

• 我们有提供标准样板的模板文件

我从未见过一个项目因为缺乏编码标准(或遵守标准)而失败,甚至对生产率有任何影响。如果你花任何时间来执行它们,那你就是在浪费钱。有很多重要的事情需要担心(比如代码质量)。

为那些喜欢遵循某些标准的人创建一套建议标准,但不要这样做。

ParaSoft的JTest对于Java来说是不错的选择。

我们的编码标准列在我们的程序员手册中,因此每个人都可以很容易地参考它们。它们之所以有效,仅仅是因为我们得到了所有团队成员的认可,因为人们不怕在代码审查期间提出标准和样式问题,并且因为它们允许一定程度的灵活性。如果一个程序员创建了一个新文件,而她更喜欢将括号与If语句放在同一行上,这将为该文件设置标准。将来修改该文件的任何人都必须使用相同的样式以保持一致。

我承认,当我第一次阅读编码标准时,我不同意其中一些标准。例如,我们对函数声明使用某种样式,如下所示:

    static       // Scope
    void         // Type declaration 
func(

char   al,                //IN: Description of al
intl6u hash_table_size,   //IN/OUT: Description of hash_table_size
int8u  s)                 //OUT: Description of s
{
<local declarations>

        <statements>
}

我以前从未见过这种情况,所以一开始我觉得很奇怪,很陌生。我的直觉反应是,“好吧,那太愚蠢了。”现在我在这里已经有一段时间了,我已经适应了这种风格,并且很欣赏我如何快速理解函数声明,因为每个人都是这样做的。