通过例子。告诉他们正确的道路。

慢慢来。不要因为他们的每一个小错误就立刻痛斥他们，要从真正重要的事情开始。

我不是我项目的首席开发人员，因此不能强加编码标准，但我发现糟糕的代码通常会迟早导致问题，当它发生时，我有一个更清晰的想法或解决方案。

通过在当时不插话，采取更自然的方法，我获得了领导更多的信任，他经常向我寻求想法，并让我参与项目的架构设计和部署策略。

可能在效果后有点晚了，但这就是一致认可的编码标准是件好事的地方。

首先，我会注意不要太快下结论。有些代码很容易被认为是坏的，尽管可能有很好的理由(例如:使用带有奇怪约定的遗留代码)。但让我们暂时假设他们真的很糟糕。

你可以建议建立一个基于团队输入的编码标准。但是你真的需要考虑他们的意见，而不仅仅是强加你对好的代码应该是什么样子的看法。

另一种选择是把技术书籍带进办公室(《代码完成》、《有效的c++》、《实用的程序员》……)，并主动把它借给别人(“嘿，我用完了，有人想借吗?”)

他们可能也认为你的风格很糟糕。让团队一起讨论一套一致的编码风格指南。同意某事。这是否适合你的风格并不是问题，选择任何风格只要它是一致的才是重要的。

我真的很喜欢EnderMB的回答，但我想补充一点:

培养一种鼓励讨论代码质量的环境，而不是将其视为敏感或禁忌。例如，我曾在一个开源项目(一个Python库)中工作，团队经常讨论新代码和错误修复。不仅可以说“嘿，我认为这样做更好”，而且这实际上是被鼓励的，也是我们用于维护高质量代码的过程的一部分。

我知道不是每个环境都有利于这种过程，但它确实对我们很有效。每一次代码提交并不一定是一次委员会会议，但它应该是完全可以接受的，您可以讨论有问题的或非最优的代码并寻求改进。毕竟，更好的代码对团队中的每个人都有好处，团队合作的一个主要概念是一起工作，而不是松散的个人团体。