那所有这些编码规则呢？

我一直支持为公司或特定项目的开发人员制定编码规则的想法。特别是如果公司的规模大于10。公司越大，需求越大。我知道很多人会不同意，但是我看到没有这些项目的项目，并且代码看起来像是彻底的灾难。

由此产生的真正问题是，如何使那些不喜欢在if语句中使用方括号，不喜欢在代码中到处使用相同的连接字符串的人，或者不使用编码规则而又不反对的人这个主意？

让他们参与解决问题，而不是与规则作斗争。我个人更喜欢“样式指南”，“编码标准”或类似的概念，以期防止膝关节“规则=坏”的反应。

但是即使这样做-我倾向于认为规则是有原因的，让头脑冷静的人转身的方法是使他们意识到，通过遵循准则，它们有助于使代码更容易为大家阅读。

有时候，同伴压力是最好的解决方案。

在我的工作中，我们使用以下三个解决方案：

1）采用代码样式检查器，例如出色的Checkstyle（对于Java）或StyleCop（对于C＃）。这些是易于配置的工具，可以自动突出显示编码样式/规则偏差。它给每个人一个中立的第三方，以决定什么是可以接受的和不可接受的。

2）采用自动保存的格式代码模板（这是使用Eclipse的示例） （Visual Studio的另一个示例），该模板将在保存时自动格式化代码。这非常适合允许某人按照自己的意愿进行编码，但所有代码在保存/提交时都采用相同的格式。我真的很喜欢这个，我们的代码从未如此一致。

3）代码审查。希望您无论如何都可以这样做，但是这些应该强调的一件事是编码规则/样式违反了约定。

除上述内容外，重要的是每个人都在同一条船上，并同意他们正在努力的样式/规则。明确指出，您不会在所有人的所有事情上都达成共识，而是要求团队做出承诺，以忠于团队的决定。确保偶尔查看选择的样式/规则，以考虑使用它们的实际经验和团队更替。

由此产生的真正问题是，如何使那些不喜欢在if语句中使用方括号，不喜欢在代码中各处使用相同的连接字符串的人，或者其他任何人，

是通过不使用括号来“硬着头皮”还是这是“硬着头皮”的要求？

选择你的战斗。我怀疑这是值得选择的之一。我不喜欢在“首次签入代码”这一详细级别附近的任何地方工作。这是团队不了解重构的危险信号。

OO 101：“重构产品何时需要执行的操作”。没过

在大型团队中，要让每个开发人员都站起来很困难，要确保他们将支架放在您认为应该去的地方-相信我吧；）。

如果您确实觉得这阻碍了您的发展，那么您将需要一个“网守”。例如，不要让人们在没有代码审查的情况下签到。让技术架构师或团队负责人检查代码并拒绝代码，直到他们“纠正”代码样式。但是，他们很快就会对此感到厌倦并适应规则，可能只在检查它们之后才进行。

当然，有些公司完全剥夺了初级程序员的签入权限。当他们最终了解了公司的编码规则后，便获得了特权。

我认为您所谈论的问题有很大不同：

如何使那些不喜欢在if语句中使用方括号的人，

除非存在明确的运算符优先级问题，否则这主要是样式/可读性问题。后者应该不是很常见，并且无论如何都可以进行单元测试，因此易于修复。前者可以轻易地陷入一场神圣的战争，而收获不多，但却给团队士气带来严重的负面影响。因此要当心- 仅推送经过尝试和测试的规则，这些规则至少已被某些团队/社区接受并证明可以工作。

或在代码的各处使用相同的连接字符串，

如果您指的是Magic Constants，那的确是维护（加上潜在的安全性）问题，因此像恕我直言，任何经验丰富的开发人员都将理解并接受这是一件坏事。

还是采用其他编码规则而不让他们反对这个想法？

您不能强迫人们同意任何编码规则-您唯一的机会是通过讨论和（有时是激烈的）辩论获得团队成员的共识和支持。您需要使用逻辑性和令人信服的参数，显示每条规则背后的价值，并说明遵循该规则将如何弥补根深蒂固的习惯带来的不便。另一方面，通过按照公认的规则，例如在签入时引入自动代码格式，努力使过渡尽可能容易。

不过，有时您只需要接受人们的意见不同，因此每个人都可以接受的编码规则在某些方面会宽容。接受这一点，并专注于可以以更少的努力来改善事情的领域。

让他们参与制定规则。这通常有助于鼓励人们关注他们。

这就是代码审查的目的。代码审阅者不应让不符合标准的代码通过。确保不要放松紧急修复的规则。不得不在压力下重新做几次才能解决问题，这将解决那些不愿第一次正确完成工作的人。

到处都有相同的连接字符串？解决方案是重构直到删除所有重复项。复制粘贴编码人员应入狱。（别笑！史蒂夫·鲍尔默是监狱长。）

但是这里真正的问题是动词“ make”。您不能让程序员做任何事情，如果您做，那是在浪费他们最宝贵的特征：从事自己关心的事情会带来深厚的智力投入。

我要解决的方式：

1. 坚持团队具有通用的编码标准。它可以是5行，但必须所有人都同意。
2. 每次您注意到一个论点都坚持要他们将其解决并放入编码标准中。如果您发现人们来回重新格式化，请将其视为一种论点。
3. 只要商定了标准项目，就看看是否有工具可以立即清理整个代码库。
4. 每隔几个月，通过编码标准，看看哪些仍然是正确和相关的。该标准只是记录人们在做什么。而且，将已显而易见的项目保持在标准中毫无意义。

编程是一项团队运动，或者是集体的艺术作品。人们所同意的并不像他们所同意的那么重要，并且善于根据需要达成新的协议。