我讨厌我们的一种编码标准，这使我发疯，如何处理它？[关闭]

免责声明：标题没有夸张，但仍然让我感到不舒服。我只是要诚实地表达，所以要加一点盐。只是假装我谈论的是编码标准，你不喜欢的工作。

编辑：我不喜欢它的事实，并不意味着我不使用它或不执行它。

我决定本着如何超越您不喜欢的标准的精神来问这个问题，而不是寻求有关如何更好地争论如何进行更改的帮助（尽管对最后一部分的任何评论都值得赞赏）。此外，我在一家大公司工作，这种改变已经存在了很长时间，而且影响很小的事情是不可能的。

该标准是专用线路上的开口弯括号标准：

somefunction()
{
    //...
}

代替*明显优越*（注意开玩笑/沮丧的语气）：

somefunction() {
    //...
}

我个人反对该标准：

• 它使代码膨胀：多余的多余行
• 很难键入：尽管这可能只是我在标准方面的苦苦挣扎，但我知道额外的一次击键并没有那么糟糕。
• 不容易阅读：我开始阅读函数声明，if语句或任何其他范围堆叠语句，而我不必寻找左括号。嵌套块与此标准只是出于某种原因使我生气。
• 由具有Microsoft IDE背景的人使用：我认为标准背后应该有一个有争议的理由（或更多理由），而不仅仅是范式。

他们的论点（以及我内部反驳他们的方式）：

• 易于阅读，因为您可以立即看到块的开始和结束位置：我不明白这一点，如果您不知道块的所有权，那么块有什么用，所以您必须向后阅读。
• 我在Microsoft IDE中使用它，然后我喜欢它：呃...好吗？
• 在标准中：*压脚*

我是唯一一个对特定标准持固执己见的人吗？您如何克服这些标准？您对此特殊标准应该是什么持保留意见（只是为了好玩）？

如果您想解决这个问题，Torvalds会引用：

糟糕的程序员会担心代码。好的程序员担心数据结构及其关系。

现在考虑，它使那些担心诸如代码标准所强制的支撑样式之类的小事情的程序员放到哪里呢？您的代码库是否是如此原始，以至于支撑是唯一值得花时间争论的问题？

有些人喜欢它，而另一些人则不喜欢。不管怎样，都会有人烦恼。这次轮到你了。吸干它并继续工作。

是否记录了团队的标准？如果是，那么样式指南中是否有任何原因？老实说，我不得不花很多时间来完成真正的工作。还有更严重的问题，但我感觉到您-仍然感到困惑（顺便说一下，我同意您的风格）。

是什么帮助我度过了难关：

1. 意识到单一样式（无论它是什么）都有真正的好处。或者至少有一堆人是这样认为的。
2. 正是您刚才所做的，写出为什么感觉不对，以便您将来可以很好地提出论点。
3. 看在上帝的份上，使用样式工具可以节省您的理智。 ReSharper的，CodeMaid，了StyleCop，JSLint的，CheckStyle的，等等 ......甚至Visual Studio会为你做它。
4. 在这个项目上踢屁股，并在可以设置标准时准备下一个。

一个约定优于另一个约定的优势*显然是任意的*。

您面临的可读性问题，或者您的队友会遇到的与您的标准相同的问题，只是对改变的心理抵触。

客观的可读性参数支持整个代码库的* consistency *。

回想一下当您确定自己对某件事是正确的，并在一段时间内意识到自己错了，或者至少是在那些年前反应过度的时候。考虑一下您可能再次出错的可能性，并给新的编码标准或处理时间说服您。

当我刚接触编码时（例如，进入职业生涯的五年时间），我自己的标准狂怒是多字标识符应该是WrittenLikeThis还是written_like_this。我什至都不会说我选了哪一个，但问题是一段时间后我改变了立场，再过一段时间我都不在乎。

用花括号描述的标准差异在很大程度上是任意的。两种方法都是同样好的方法，对于一家公司而言，只要每个人都做同样的事，那一切都是好的。

您所说的“明显优越”是人们谈论“他们习惯”时所谈论的那种优越。

您会足够快地习惯它，并且在一年左右的时间内，另一种方式将是“明显优越”。

简而言之：应对它。

这个特别的主题相当于那些偏爱一种风格而不是另一种风格的人之间的宗教战争。很少有人会感到矛盾。

归根结底，对与错都不对。

出现样式指南和编码标准有多种原因-一个关键方面是确保布局均匀，目的是减少明显的错误数量并提高可维护性。

我是唯一一个对特定标准持固执己见的人吗？

简短的回答是“不”，您不是唯一的一个。但是还有更多重要的事情要担心。即使采用已输入的标准，也总是会妥协的-见证将其纳入C99和C12的某些方面对我来说毫无意义。

甚至MISRA-C（我直接对其有影响）也包含我个人不同意的项目-但我可以理解为什么其他人会觉得有道理。

你如何克服这些？

这就是答案所在-而不是专注于为什么您个人不喜欢它，而是试着理解为什么同意它的人如此。

通常会引入规则（在用螺栓拧紧马路后关上稳定的门）以解决先前的问题。而且，如果该规则仍然不合理，请与标准所有者联系，然后尝试并“教育”他们。

我认为您只需要继续学习即可。我将尝试用我自己的观点来回答您的笔记：

• 膨胀代码

  额外的一行代码根本不会膨胀代码，除非您在单个类中编写100多个方法，否则会增加数百行。再说一次，如果在一个类中有成百上千个方法，那么您将完全遇到另一个问题。

• 很难打字

  我不能再对此表示反对，无论如何，您必须按回车键才能进入下一行。那很难打字呢？

• 难以阅读

  我觉得一段代码中的每一行都应该具有特定的功能。接下来，您需要在一行中定义方法名称，然后在单独的行上使用大括号和开括号。

• 由具有MS IDE背景的人使用

  嗯.....好吗？

总而言之，似乎您很想成为.Net开发人员，而不是其他任何类型的开发人员，就好像他们的劣等，因为他们使用的是默认使用此标准的IDE。

我是唯一一个对特定标准持固执己见的人吗？

当然不是。确定编码标准的会议太可怕了！他们花了几个小时，参与者亲自投入了使自己喜欢的标准（除我以外，总是错误的）体现在标准中的特质。最后，没有人对结果感到满意。如果有什么事情比编码标准会议更糟，那就是确定标准之后的几个月中的正式代码审查会议：有些人尝试采用该标准，而另一些人（有意或无意）忽略了该标准，您得到了几小时的反馈，例如：在SillyFileConverter.cpp的132、142、145、181、195和221行上，当编码标准明确指出应在下一行时，将开括号放在同一行上！

你如何克服这些？

会议以自己的方式提供帮助。即使您完全同情有条件的左括号的那个家伙，您仍然会因为不仅仅浪费时间并遵循愚蠢的标准而浪费时间而对他感到恼火。如果这个家伙是一个curmudgeon，并且一遍又一遍地做同样的事情，那会变得更加烦人。对这种行为感到烦恼使得以与您喜欢的样式稍有不同的方式来证明写作的正当性变得更加容易- 毕竟，您当然不希望成为那个人。

即使您没有进行无休止的正式代码审查，也可以尝试专门检查自己的代码是否符合标准。您对标准的看法并不重要，您只是在比较编写的内容与标准的内容。如果您每次不遵守时都冒充自己，这可能会提供一些负面反馈，帮助您采用该标准。

通过这种事情，我记得在利利普特（Lilliput）的格列佛（Gulliver）。小人国一直在为开一个煮鸡蛋而战。（原始的大端，小端）。

以此为自己嘲笑自己的机会，他们在业务中的使用并不多。

您的特定示例很不幸，因为有些人会同意而有些人不会。我不同意你的反对，例如，我相信许多其他人也会同意，正如我相信许多其他人也会同意他们的观点一样。我几乎认为这个问题应该解决，因为它太主观了。

但是，关于如何处理您不同意的标准的问题可能会更容易回答。我认为答案是，只要存在并同意使用了样式准则，那么答案就是咧着嘴笑，忍受它并加以处理。考虑到保持一致性更为重要。如果指南不正确或有错误，可能会有改变的论点，但这是风格上的，因此除了个人喜好外没有其他论点。

我最初来自Java背景，因此遵循您提到的标准。然后，我转向使用您讨厌的样式的更多C ++和C＃。但这没有正确或错误的答案。更重要的是每个人都要遵循一个标准。如果这样的编码标准在风格上没有明显的错误，那么试图争论它只会在团队中引起摩擦。

格式化程序+签入钩子是一个好的开始。但这还不够，因为您写的内容并不像您整日凝视的内容那么重要。在某些情况下，Emacs眼镜模式的方法（使文件保持其样式但显示得更接近您的样式）是很有吸引力的。

我与它的经验-面对它到底是书面的问题CamelCapsVS underscore_separated-是它迅速成为多于帮助烦人，但几个星期变得平滑我的过渡（勉强）接受公司的风格，以及所提供的插座来表达我的愤怒（“啊，我讨厌它，让我再次调整设置...在那里，至少我做了一些事情 ”）；-)

无论如何，Glass模式无法处理大括号位置，您可能不使用Emacs，也不是仅在编辑器中读取代码：-(
但是最后一点也是一个机会-如果您大部分时间都在阅读代码，一个单独的工具，您可以破解该样式来转换样式，而不必担心往返重新格式化的噪音-因为它是只读的；特别是，如果您在某些Web界面中读取代码，请使用Greasemonkey。

以下是一些缓解轻度问题的简便方法：

• 选择较宽但不太高的字体，以恢复丢失的屏幕线条。

  • 如果可用，请更频繁地使用全屏。

• 设置大括号，使其以微妙的颜色（和较小的字体？）突出显示，使其比其余代码更不可见。缩进应该足以阅读，尤其是。与来自{线条 ...

• 确保您的编辑器在结束时突出显示匹配的开括号}-当您的眼睛本能地转到错误的位置时，可能会有所帮助。

• 关于“难以输入”：获得一个真正的编辑器，将其配置为在按下时自动打开新行{。

忍受它。

显然，这是化妆品，它不会改变代码的质量或作为开发人员的工作效率。没有什么值得争论的。

对于这种编码标准，我每天都会选择整个代码库的一致性和任何特定（甚至是合理的）“宗教”方法的可读性。

将其视为大多数团队成员关于不太重要的问题的民主决定可能会帮助您克服它。

这是标准的：

http://doh-san.blogspot.com/2005/10/five-monkeys.html

多数人说“其标准”是遵循“五只猴子”原则。

只需继续使用所需的样式即可。然后使用一些代码美化器 将代码更改为标准格式，或者使用自己的小型应用程序将代码从您的样式转换为给定的标准样式。在检入代码之前，请使用美化器。
您也可以执行相反的操作，以将签入的代码从标准格式更改为您的格式。