Answers:
出于某些原因，应该在其中设置编码标准...并且应检查不符合项。
但是，并非所有违规都应视为错误-就像并非所有编译违规一样。画线的地方必须是公司和工具的决定。
例如，MISRA将其规则定义为“必需”和“咨询...”。我建议咨询将允许构建继续进行。
如果运行静态分析工具（例如PMD，StyleCop / FxCop）的持续集成服务器是否应实施编码标准/样式，并且如果未遵循标准，则构建失败？
那些连续的集成检查需要非常非常快。任何重大的延迟都将意味着您的程序员将在等待结果的同时投入精力并失去对思维过程的跟踪。延长比赛时间，他们会投入精力并喝杯咖啡，或者与队友聊天，了解一些运动队最新的表现糟糕。这些延误会适得其反。最好将某些事情留给夜间构建或代码审查。
哪些类型的规则不应用于使构建失败？
首先是主观的。您如何执行“代码应为自我记录或注释良好的”规则？“没有魔术数字”规则？这些最好留给代码审查。
另一类是违反已被豁免的规则的行为。给定任何可观的代码库，不可避免地会有一些代码块违反标准是正确的做法。
作为软件质量改进计划的一部分，我们最近对一系列代码嗅探进行了编码，以集成到我们的构建过程中。
作为PHP应用程序，我们进行了大量构建，没有真正的编译过程，因此构建实际上是一个单元测试/静态分析/运行器，因此我们可以花一些时间来做。
我们遇到了一些代码质量问题，还有一些遗留问题的旧代码。
首先，如果提交不会失败，则将忽略该提交，我们开始根据“所需”编码标准来确认提交，并以不符合标准的错误来使提交失败。
维护工作要停下来，即使是对遗留组件的最简单修复，也要求开发人员重新格式化大量的源代码，并且构建经常被破坏。不用说，我们已将错误更改为警告，现在，它们已被忽略，并且“基本上”毫无意义。
所以我会这样说（从艰难的经验中学到）。
确保代码库的标准与所执行的标准足够接近，以确保您不需要开发人员立即重新格式化大量的代码。或者..您已准备好并期望增加工作量。
作为一个具有庞大交付需求的小型团队，我们无法负担将团队转换为庞大的重构业务的负担。现在，我们的编码标准主要由人工审核处理，并且将其遗产重新编写为持续改进计划的一部分。
当我说警告“基本上”毫无意义时，我们现在就使用它们来记录统计数据，从而使我们能够测量应该不断显示改善的kpi。
当我们再次执行代码嗅探时，我们将开始工作，并一次引入一些嗅探，直到我们执行了标准。
这将取决于您的最终目标和策略。
在CI服务器中强制使用所有提及的标准似乎很有利可图。但是，对于大型（超过6个开发人员）开发团队，如果每次对服务器的提交都完成了，则可能不切实际。提交后等待服务器响应的时间不应太长。这可能会导致一些停机时间。
但是，如果代码（实际的变更集）存在依赖关系问题或无法编译，则阻止提交是完全合法的。但是，由于代码布局和某些命名约定而导致的代码失败可能过于严重，对CI服务器提交规则而言并不是至关重要的限制。
但是，如果在晚上构建期间应用该规则，则很有可能会很有帮助。
另外，重构工具可以帮助实现和学习标准-例如开发人员使用的Resharper或JustCode。