我是否应该仅遵循工作场所中已建立的约定而遵循不良编码风格？

我已经工作了大约一年了。我主要在GUI界面中工作，该界面使用C后端的方法，但是除了返回值外，我通常不必处理它们。考虑到我们的局限性，我们的GUI结构相当合理。

我的任务是向程序的命令行部分添加功能。这些功能大多数都长达300行，难以使用。我正在尝试收集其中的一些信息以获取特定的警报信息，但在保持井井有条的过程中遇到了麻烦。我知道我要通过一个长函数来使测试变得更加复杂。

我应该按照现有功能的样式将所有功能都保留在一个巨大的功能中，还是应该将警报封装在它们自己的功能中？

我不确定是否适合违反当前的编码约定，或者我是否应该硬着头皮让代码编写自己的代码更加混乱。

总而言之，我正在比较

showAlarms(){
    // tons of code
}

反对

showAlarms(){
   alarm1();
   alarm2();
   return;
}

alarm1(){
    ...
    printf(...);
    return;
}

编辑：谢谢大家的建议，我决定我将设计我的分解代码，然后询问他们想要什么，如果他们想要全部融合在一起，我可以从分解的代码中切下来，然后将其重新变成1大功能。即使他们希望所有代码都在一个定义中，这也应该允许我编写它并更轻松地对其进行测试。

更新：他们最终对分解式代码感到满意，并且有一个以上的人感谢我树立了这一先例。

这确实是在您和您的队友之间。没有其他人可以告诉您正确的答案。但是，如果我不敢在这两行之间读一读，那么您称这种样式为“不良”的事实可以提供一些信息，表明最好慢慢来。实际上，很少有编码样式是“不好的”。我自己有些东西我不会用，但是它们总是带有韵律或理由。在我看来，这表明故事的内容比您到目前为止所看到的更多。问周围将是一个非常明智的选择。可能有人知道您不知道的东西。

我个人是在首次尝试实时执行关键任务编码时遇到这个问题的。我看到了这样的代码：

lockMutex(&mutex);
int rval;
if (...)
{
    ...
    rval = foo();
}
else
{
    ...
    rval = bar();
}
unlockMutex(&mutex);
return rval;

作为我曾经是一位聪明又有光泽的OO C ++开发人员，我立即通过手动锁定和解锁互斥锁而不是使用RAII来告知他们存在的错误风险。我坚持认为这样做更好：

MutexLocker lock(mutex);
if (...)
{
    ...
    return foo();
}
else
{
    ...
    return bar();
}

更简单，更安全，对吧？当编译器可以为您做时，为什么要求开发人员记住在所有控制流路径上解锁其互斥锁！

好吧，我后来发现的是程序上的原因。我们必须确认，是的，软件确实可以正常工作，并且我们可以使用的工具数量有限。我的方法在不同的环境中可能会更好，但是在我正在使用的环境中，我的方法很容易将验证算法所需的工作量增加了十倍，因为我只是将C ++ RAII概念引入了一段代码中所遵循的标准实际上更适合C风格的思考。

因此，对我来说，看起来很糟糕，非常危险的编码风格实际上是经过深思熟虑的，而我的“好的”解决方案实际上是危险的解决方案，它将在以后引起问题。

所以问一下。肯定会有一位高级开发人员可以与您合作，以了解他们为什么这样做。或者，有一位高级开发人员可以帮助您了解代码这一部分中重构的成本和收益。无论哪种方式，请四处询问！

老实说，您认为拥有300行难于使用的功能仅仅是样式问题吗？因此，遵循一致的错误示例可以使整个程序保持更好的状态，因为它具有一致性吗？我想您不这么认为，否则您不会在这里问这个问题。

我的猜测是这些功能之所以这么长，是因为在我们的业务中，有许多平庸的程序员只是将功能堆叠在功能之上，而不关心可读性，代码质量，正确的命名，单元测试，重构，而且他们从未学会创建正确的抽象。您必须自己决定是要跟随一群人，还是要成为一个更好的程序员。

附录，由于注释：“ 300行”和“难于使用”是恕我直言强烈表示错误代码。以我的经验，很可能没有某种“隐藏的技术原因”，导致这种代码无法以更具可读性的方式实现，这与Cort Ammon的答案示例相当。但是，我同意Cort的观点，您应该与团队负责人讨论这个问题-不是找到无法更改代码或这种“样式”的晦涩原因，而是要找到如何安全地重构代码而不破坏事物的原因。 。

没有。

在《实用程序员》一书中，作者谈到了“ 破窗理论”。

这个理论状态：

考虑一栋破窗户的建筑物。如果不修理窗户，则有可能破坏者破坏更多窗户。最终，他们甚至可能闯入建筑物，如果空置，可能会成为棚户区或小火。

或考虑人行道。一些垃圾堆积。不久，更多的垃圾堆积。最终，人们甚至开始将垃圾袋从那里的外卖餐厅丢下，甚至闯进汽车。

在这本书中，作者在这一理论和代码之间写了一条平行线。找到这样的代码后，您将停止并向自己问同样的问题。

答案是：不会。

一旦您离开了这个破碎的窗口（在我们的例子中是糟糕的代码），这将产生使每个人都将破碎的窗口抛在后面的效果。

有一天，代码将崩溃。

将清洁代码和清洁编码器的副本提供给所有人。

而且，当您在学习本主题时，TDD副本也是一个不错的选择。

是的，去吧。结构！=样式

您在说的是结构，而不是风格。风格指南没有（通常）规定结构，因为通常选择结构是因为它适合于特定问题，而不是适合组织。

小心

请确保您不会在可能未发生的其他方面造成负面影响。例如，

• 确保您没有使差异或代码合并复杂化，因为您消除了与现有代码的任何相似之处。
• 确保异常流正确冒泡，并且堆栈痕迹不会被一大堆难以理解的废话污染。
• 确保您不会意外暴露会直接引发问题的公共入口点（请勿将其放置在地图中和/或不导出它们）。
• 不要弄乱全局名称空间，例如，如果所有较小的函数都需要某种先前在函数局部范围内声明的全局上下文。
• 确保查看所有日志，并问自己是否在支持团队中，如果您看到的代码生成的日志与您从未触摸过的任何代码的日志交织在一起，是否会造成混淆。
• 确保您确实遵守现有样式，例如，即使他们使用的是老式的匈牙利符号，并且会使您流血，也要与通用代码库保持一致。与阅读匈牙利符号相比，唯一更痛苦的事情是阅读代码，该代码使用十几种不同类型的符号，具体取决于谁编写了什么。

要温柔

请记住，您是团队的一员，尽管良好的代码很重要，但是团队成员保持假期时编写的内容也很重要。尝试坚持对习惯旧样式的人有意义的流程。仅仅因为您是会议室中最聪明的人，并不意味着您应该在每个人的头上讲话！

我不认为这是一种代码约定。我将其视为不了解如何编写易于理解的可维护代码的人。我会按照您的建议将您的代码分解为不同的功能，并对您的团队进行此操作的好处进行教育，同时尝试理解为什么他们认为300行功能可以接受。我会很感兴趣听到他们的推理。

答案在代码审查中。

真正的问题是，如果您提交完善的代码，您将成为唯一愿意使用它的人吗？

我像这里的大多数人一样，相信300个行功能是可恶的。但是，将Windex带到垃圾填埋场并不会带来多大好处。问题不在于代码，而在于编码员。

仅仅正确是不够的。您需要向这种风格的人推销。至少在阅读时。如果您不这样做，您最终会像这个可怜的家伙一样：被开除，因为您的技能远远超出了您的同事

从小开始。四处询问，看看是否还有其他人喜欢较小的功能。更好地窥探一下代码库，看看是否可以找出谁编写最小的代码（您可能会发现最丑的代码是最早的代码，而当前的编码人员正在编写更好的代码）。与他们讨论此事，看看您是否有盟友。询问他们是否认识其他有相同想法的人。询问他们是否认识到讨厌小功能的人。

召集这个小组，讨论进行更改。向他们展示您想要编写的代码类型。确保他们可以阅读。认真对待任何异议。进行更改。批准您的代码。您现在可以在身后举行会议。这些中的更多一些，您可以生成一个一页纸的文档，该文档明确接受您引入的新样式。

会议是令人惊讶的强大功能。他们可以产生影响力。消极影响力是您用来与反对这一运动的人作斗争的方式。这就是这一点。运动。您正在争取改善现状的权利。人们害怕改变。您将需要甜言蜜语，哄骗和刺耳。但是如果运气好的话，您会变成正确的被接受。

有时，您必须顺其自然。

就像您说的那样，您受命在现有的工作代码库中实现功能。

不管混乱如何，我都知道很容易清理它。但是在商业世界中，您并非总是有机会重构代码。

我想说的是做您被要求做的事情并继续前进。

如果您认为值得重构或重写，则需要将其提出来与团队讨论。

在声明这些做法不好之前，我将首先迈出一步，以了解采用大方法和其他做法可能会导致不好的原因。

然后，您需要确保测试覆盖率非常高或确实很高（就可以在不进行重大重构的情况下进行）。如果不是这样，即使您没有编写代码，我也将努力使覆盖率达到很高。这有助于建立融洽的关系，而您的新团队将更加重视您。

一旦涵盖了这些基础，他们中没有一个人会挑战您。作为奖励项目，进行一些微基准测试，这确实会增加您的案子。

通常，您的语言表达方式对改变代码文化大有帮助。以身作则。甚至更好的是，等待一段您可以编写的代码-对它进行重构和单元测试，中提琴-您将被听到。

这类问题基本上是“ 请介意我的队友 ”。互联网上的随机人无法做到这一点，因此您获得的所有答案都只是人们对编码风格的个人看法。共识是较短的方法是更可取的，但是您自己似乎已经这样认为，因此无需重申。

因此，当前的代码库似乎使用了与您喜欢的编码样式不同的编码样式。你该怎么办？首先，您需要弄清楚：

1. 这是您当前团队支持的故意设计决策吗？
2. 他们是否要您遵循这种风格？

只有一种找出方法。询问。

具有长功能可能有多种原因。这可能是因为该团队认为长功能优于多个短功能。也可能是因为它是遗留代码，并且团队更喜欢新代码遵循更简洁的设计。因此，如果您不与团队交谈并了解他们的推理，那么任何一种选择都可能给您带来开发人员麻烦。

有不同级别的“样式”。

在一个级别上，通常是编码约定的一部分，这意味着在哪里放置空格，空白行，方括号以及如何命名（混合大小写，下划线等）。

在另一个层次上是编程模型，有时诸如避免静态操作或在抽象类上使用接口之类的方法，如何公开依赖项，甚至可能避免某些深奥的语言功能。

然后是该项目正在使用的库和框架。

有时，功能大小会有最大限制。但是很少有最低限额！因此，您应该找出其中哪些功能被视为重要，并应予以尊重。

您需要确定团队是否不利于重构现有代码，这应该独立于可能的情况下添加新代码来完成。

但是，即使他们不想重构现有代码，也可以为添加的新代码引入一些抽象层，这意味着随着时间的流逝，您可以开发更好的代码库，也可以将旧代码迁移为维护它的要求。