一致的代码样式的实际价值是什么

我是顾问团队的成员，该团队为客户实施新的解决方案。我负责客户端代码库（React和javascript）上的大多数代码审查。

我注意到一些团队成员使用独特的编码模式，以至于我可以从一个样式中随机选择一个文件，以告诉谁是作者。

示例1（一次性内联函数）

React.createClass({
  render: function () {
    var someFunc = function () {
      ...
      return someValue;
    };
    return <div>{someFunc()}</div>
  }
});

作者认为，通过为someFunc分配有意义的名称，代码将更易于阅读。我相信，通过内联函数并添加注释，可以达到相同的效果。

示例2（未绑定函数）

function renderSomePart(props, state) {
    return (
      <div>
        <p>{props.myProp}</p>
        <p>{state.myState}</p>
      </div>
    );
}

React.createClass({
  render: function () {
    return <div>{renderSomePart(this.props, this.state)}</div>;
  }
});

这是我们通常的做法（避免通过状态和道具）：

React.createClass({
  renderSomePart: function () {
    return (
      <div>
        <p>{this.props.myProp}</p>
        <p>{this.state.myState}</p>
      </div>
    );
  },
  render: function () {
    return <div>{this.renderSomePart()}</div>;
  }
});

尽管这些编码模式在技术上是正确的，但它们与代码库的其余部分，Facebook（React的作者）在教程和示例中暗示的样式和模式都不一致。

我们需要保持快速的步调，以便按时交货，而且我不想给团队带来不必要的负担。同时，我们需要处于合理的质量水平。

我试图将自己想象成客户的维护开发人员，面对这样的不一致问题（每个组件都可能需要您了解另一种做同一件事的方式）。

题：

客户及其维护开发人员认为，一致的代码基础与允许像这样的不一致之处得以保留并可能蔓延的价值是什么？

代码传输优势

React在您的情况下，遵循库提供的模式意味着您所交付的产品将由熟悉React的其他开发人员轻松选择和维护。

潜在的向后兼容性问题

某些库可能会有新的主版本，如果您的模式有很大不同，则向后兼容性可能会受到影响，从而减慢/停止您的未来升级。我不确定如何React处理新版本，但是我以前已经看到过这种情况。

团队中的新成员开始更快地生产

如果您遵循作者提供的内容，则很有可能会使用您的框架来聘请有才华的开发人员，并从系统中更快地启动他们，而不是教新的模式。

潜在未发现的问题

将来可能存在您的方法尚未发现的问题，这些问题已由作者的方法解决。

话虽如此，创新始终是一种风险，如果您强烈认为自己的方法更好并且对您的团队有效，那就去创新吧！

不一致让你停下来想一想，为什么，这和其中：

• 当您阅读部分代码并发现它使用与其余代码不同的样式时，您会感到奇怪- 这部分为什么不同？是否有我需要注意的特殊原因？这很危险，因为如果确实有理由要使该部分与众不同，那么您需要意识到这一点，否则您可能会创建一些讨厌的错误。因此，与其去思考导致您接触该代码的原始问题，不如现在就浪费时间去思考它为何与众不同，因此您无法弄清楚，因此您去找原始作者问他们，也浪费了他们的时间，并且更糟糕的是，在此过程中，您和他们都失去了正在解决的问题的思维模式。

  乘以团队中需要触摸/读取该代码的所有其他开发人员。

• 当您需要添加到使用多种样式的代码时，需要停止并确定要使用哪种样式进行添加。您必须做出足够重要的决定-浪费时间浪费时间思考无关紧要的决定。

• 当风格是一致的，很容易浏览周围的代码，因为一致性可以帮助您快速找到这里的东西所在。使用不一致的样式，甚至拼写也变得更加困难，因为您不知道所寻找的东西正在使用哪种样式。

该代码可能写得很好，但并不完全一致，因此某些客户不会在意。当情况开始恶化时，您是否要再给他们敲门声？如果我雇用一家公司从事多开发人员项目，而他们没有向我表明他们拥有编码标准并遵循该标准，那么我将持怀疑态度。

我们需要保持快速的步调，以便按时交货，而且我不想给团队带来不必要的负担。

只要编码标准不是太疯狂，每个人都应该不难加入。项目之所以停滞不前，是因为人们不知道要编写或不编写什么代码，也不是因为键入和格式化了。当您花费不成比例的时间来坚持时，您会知道自己已经走到了尽头。希望这不是您的第一个牛仔竞技表演。

进行自己的测试 所有您需要做的就是将分配从一个开发人员切换到另一个开发人员，并让他们完成其他人的文件。他们是否花费时间将内容重新格式化为他们的版本？太难了吗？对于您的客户的维护团队来说，情况将会变得更糟。

我对待代码样式的运气很好，就像我对待自然英语的写作样式一样。从对话式的英语（模仿我们在日常对话中的说话方式）到正式的英语（其含义通常很繁琐，而且总是非常精确），其样式多种多样。

考虑一下您希望最终产品看起来像什么。有些情况非常支持使用当时最好的任何结构。其他的则需要统一的节奏和结构。如果您的产品最好用正式英语编写，则尤其如此。在这种情况下，口语化可能会有所帮助，但它们会破坏产品的总体感觉。

通常，您的编码标准越一致，开发​​人员需要花费更少的精力来吸引他们注意有趣的事情。如果您支持多种不同的编码标准，则开发人员在宣布自己所做的事情不寻常或独特时必须大声疾呼。试图表达开发人员认为重要的尝试通常会掩盖代码本身的动态范围。发生这种情况时，很容易漏出错误，因为很难看到它们。

另一方面，您的编码标准越宽松，开发人员就必须越自由地调整其语法以解决该问题。具有讽刺意味的是，与赞成编码的标准说法相反，过多的标准化会导致代码结构过高，这也很容易使错误流失。

您正在寻找自己团队的快乐媒介。

正如其他一些人指出的那样，当维护开发人员不得不落后于您时，具有不同样式的一段代码将导致他们停下来并试图弄清楚该部分的特殊之处。还有非常实际的风险，即不一致的样式会传播到其他部分，从而在以后造成巨大混乱。

我印象深刻的是，您已经知道了这个问题的答案，如果不是这个问题，您甚至都不会面对它：

我们需要保持快速的步调，以便按时交货，而且我不想给团队带来不必要的负担。

这似乎总是一种普遍的权衡……快速地做与正确地做。只有您可以评估在更改客户截止日期后牺牲良好编码习惯的后果。但是，我必须同意JeffO的意见，因为他观察到遵循（可能不寻常或违反直觉的）编码风格不会使您的团队放慢速度，以至于截止日期明显缩短。

尽管我对该概念已经了解多年，但直到最近才学会了“ 技术债务 ” 一词。如果您现在不遵循纪律的作风，您确实需要考虑最终必须偿还的技术债务。

不幸的是，正如eBusiness所述，除非您的客户精通技术或者以后自己要维护代码，否则他们很难理解一致的编码标准的价值。但是，任何有理智的商人都应该能够理解“现在进行一些预防性维护”（以良好的编码形式）“将有助于避免以后的大量维修成本”（以浪费开发人员以后清理时间的形式）的概念。一团糟）。

这里最受好评的答案重复了容易达成共识的理论最佳实践，详细说明了我们所有人希望代码库如何。但是真正的代码总不会像那样。如果您尝试创建完美的代码库，则几乎不可避免地会失败。这并不是说我们不应该尝试做得更好，但是我们设定目标与实际可实现的目标之间必须有一个极限。

对次要内容的过多关注可能会失去对更重要问题的关注，例如如何以整体上最有效的方式解决工作。

我不会将第一个示例称为样式，样式是没有明显对错的选择，在这种情况下，额外的功能是没有膨胀的代码膨胀。它只有两行，仍然易于阅读且易于修复，因此该示例本身没有什么大问题。

更大的问题是令人费解的代码膨胀。包装函数，类层次结构以及各种其他构造，其中的周围代码非常复杂，以至于它们显然没有真正的用途。如果代码中出现明显的膨胀，那么可能会出现很多非明显的膨胀。做某事比较困难，也很难发现，但问题更大。

关于客户

客户倾向于专注于获得能够满足其需求的有效产品。即使您有几个担心代码质量的客户之一，这也将是第二优先级，他们的代码质量观念可能与您的想法并不完全一致。客户公司可能有自己的程序员，但是仍然由管理层来决定您是否做得很好，并且管理层很可能甚至不知道代码质量意味着什么。

这与差异的易读性息息相关。如果代码风格出现问题，差异将隐藏对程序没有任何语义意义的更改，并且可能使合并变得困难或不可能。