我们需要编码约定吗？

有些事情自然而然地发生了，我们忘记了是否还有其他方法。 就像早晨的太阳升起，傍晚的太阳一样。 但是科学家提出了这个问题，即使太阳仍然在早晨升起并仍然在傍晚落下，我们仍对此收集了很多知识。 它类似于每个职业。 我们做事情，遵循程序，不问问题：为什么？ 我们应该吗？

在某些情况下，我们遵循某些程序，因为这是我们一直以来的做法。 我们以行形式编写程序代码，因为这是在Hollerith卡上创建的在RPG中记录代码的唯一方法。 您甚至都不知道Hollerith卡是什么，但是您仍然在编辑器中编写代码行，并且建议的最大行长仍然很多时候是72个字符。 我们应该将代码写成72个字符长的行吗？ 不，显然。 很多时候我们不这样做。 现代的编辑器和屏幕使更长的行变得更可行。 仍然存在使代码更易读的最大长度。 如果我们要求的话，像Eclipse这样的集成开发环境会排太长的行。 没人质疑。 人们在问的是线的实际长度。 应该是80个字符，130或125个字符还是其他？ 可以确定的一件事是：在团队中进行编码时，应该只有一个已决定并已达成共识的限制。 可悲的是，设置编码标准有时是达成共识的良好基础和来源。

根据我的实践，在开始一个项目之前，最重要的Java编码问题（就辩论的温度而言）是：

“关键字'if'和左括号之间应该有空格吗？”

您可能会笑，但是只需查看以下两个示例代码段：

if( debugIsSwitchedOn )log.debug("Here we go");

和

if ( debugIsSwitchedOn )log.debug("Here we go");

现在您可以理解，回答此问题并对此达成共识可能会使项目成功或失败。 在瀑布式方法和敏捷方法之间进行适当选择是一个自由选择的问题，并不会像该问题那样真正影响项目的结果。 至少如果我通常根据辩论的努力来衡量重要性。

现在你以为我在开玩笑。 是的，但是从另一个角度来看：

如果在关键字“ if”和左括号之间是否有空格并不重要，那么为什么人们花很多精力和精力来讨论它？

这样的细微差别似乎对开发人员很重要。 对于开发人员来说重要的是对项目很重要的。 不满意的开发人员无法交付成功的项目。

这不是一个硬编码的区域，例如您可以尝试，测试，衡量并最终定论的是Tomcat中的反射性能或线程本地用法。 这不是我不是专家的心理学，但是我仍然有编码经验，并且对提出的问题有自己的想法。 在讨论了一个主题之后，我们不是专家，至少是这样一个争执的良好理由，因为它比基于事实更注重宗教性，例如'if'和'（'之间的空格。

代码归开发人员所有

如今，敏捷方法论认为代码属于该组。 任何人都可以修复代码的任何部分。 在过去，情况并非如此。 我们没有遵循这样的“昂贵”和严格的规则。 开发人员是孤独的狼，对自己的代码负责。 共享代码需要花费其他成员从开发小组的其他人那里学习代码的成本。 从长远来看，考虑到代码的维护成本甚至在调试会话期间的第一个发行版开始之前，它的成本就会降低。 即使共享代码不是人的本性。 深入人心的开发人员仍然是孤独的狼，老实说，当我编写代码时，我是一个人。 我常常处于一种流动状态，意识到我花在编码上的最后十分钟实际上是一个多小时。 有足够的经验，我不愿意与他人共享代码，解释是否需要什么以及为什么存在。 （顺便说一句：需要广泛的解释已经是一种代码味道，除非另一边是初级的，在这种情况下，这种解释是一种更多的教育。）

这意味着我们内心仍然拥有代码。 开发团队的每个成员在必须修复错误，扩展功能时都应该拥有拥有有效代码的能力。 细微差别会极大地影响用户的感觉，就像我们通常格式化代码的方式一样。 我在IDE中打开源代码，使用设置的颜色和字体外观（已经使它有点舒适）看到了代码，并尝试理解代码。 如果编码约定与我的代码完全不同：这是一种干扰。 在某种程度上，我可以说服自己不要关注下括号的事实，就像我们在编写C＃时所做的那样，但是在Java中编写代码时却很烦。 那不是我们通常这样做的方式。 Eclipse，IntelliJ甚至某些vi宏都有助于重新格式化，但随后在GitHub中比较pull请求时，我们浪费了时间：大多数格式都会有很多更改。 我们将信息丢在杂讯中。

如果该小组有编码约定，那么即使由其他程序员开发，该代码也将看起来更像我的代码。 我会看的，我会更容易理解的。 您不应低估这种效果。

实际的编码约定并不重要

更重要的是该组只有一个（只有一个）。 在项目开始时解决它是增加团队凝聚力的好话题。 即使讨论方向错误，最终决定也不是最佳选择，您还能放松些什么？ 关键字“ if”和“（”？人之间的空格，尤其是在最近形成一个群体时，必须冒昧地锻造，锻造通常是在高温下进行。没有真正的伤害？

翻译自: https://www.javacodegeeks.com/2015/11/do-we-need-coding-conventions.html