过去，我在SoftwareEngineering.SE上就此主题撰写过很多文章，而我本人也遇到过类似情况。因此，在阅读您的问题时，我将尝试给出一些提示和重点。
但首先，让我们谈一个重要方面：您在公司中的角色。
你的角色
您可能有老板的明确授权来增强功能，并且在层次结构中还需要其他开发人员来聆听您的命令。或者，您可能处于同龄人之中，具有相同的角色和相同的权限，您的选择仅是……好……一种意见。
在这两种情况下，重要的是您在层次结构中的位置更少，而更多：
其他开发人员对您的看法。如果他们把您当作一个讨厌的人问他们愚蠢的事情，您将不会走得很远。我见过很多情况，技术领导者和项目经理对团队绝对没有影响，因为团队知道（或认为）那些“领导者”不需要技术背景来做出决定。另一方面，我已经见过一些开发人员，他们实际上受到了同行的倾听，因为他们知道这些开发人员很熟练并且经验丰富。
您的团队有多扎实，是什么激励他们。想象一家公司，每个开发人员每个月都要支付KLOC费用。您对同事说什么风格很重要吗？可能不是，因为很少有人希望得到较低的报酬。通常，如果这不是一个团队，而是只有一群人在同一项目上工作，那么您将无济于事。
因此，您可以决定是否值得进行任何更改。如果您没有发言权，也没有团队凝聚力，那就去找另一份工作。如果您是一个有才华，受人尊敬的开发人员，并且拥有强烈的团队合作感，即使面对老板或其他团队的敌意，您也可以相对轻松地进行改进。
在所有情况下，至关重要的是不要对团队施加压力。工作与他们，而不是打击他们。不要给他们命令，而是引导他们实现目标。
现在，提示。
样式
我曾经很好地要求遵循大多数现有代码的编码风格和格式（很遗憾，我们没有正式的编码风格文档）。但这没用...
当然不是，因为这不是应该做的方式。
因此：
不要进行样式评论。这是样式检查器的工作。那些可爱的应用程序对您的大脑有一些好处：它们可以在几毫秒内（而不是数小时或数天）检查整个项目，并且它们不会犯错误并且不会遗漏样式错误。
不要编写自己的样式标准。无论如何，您都会做错事情，而您的同事会告诉您您做出了错误的选择。
不要强迫开发人员修复2000个样式错误。
在提交时自动执行样式。样式错误的代码在版本控制中没有位置。
从项目开始就做。在现有项目中设置样式控制是很难甚至不可能的。
有关更多信息，请阅读SE.SE上其他答案的第一部分。
也：
- 不要太严格。例如，编写
jslint兼容代码很烦人，因此应仅在绝对需要时（或者如果团队中的所有成员都乐于使用它）进行编码。静态检查工具也是如此。例如，.NET的最高级别的代码分析可能会非常压抑和令人沮丧，而带来的收益却很少。另一方面，同样的工具集在中等水平上被证明是非常有用的。
代码审查
既然您无需在代码检查期间费心处理样式，您就可以专注于更有趣的内容：增强（与修复）源代码。
不同的人对代码审查的反应不同。有人认为这是一个机会。其他人讨厌它。有些人会听您说给他们的一切，做笔记，甚至不讨论，即使他们可能是对的。其他人则试图就每一点争论。您可以根据自己的性格找到与每个开发人员打交道的方法。通常有助于：
私下进行代码审阅，尤其是在开发人员初级且编写了非常糟糕的代码时。
证明没有什么私人的：您正在查看代码，而不是个人的技能。
显示代码审查的实际目标。目的不是要显示开发人员有多糟糕。目标是提供改进机会。
永远不要争论。您并不是要说服您，而是要提供您的专业知识。
永远不要以为受审者是唯一可以从评论中学到东西的人。您也可以通过阅读代码和询问有关您不了解的部分的说明来学习。
完成代码审查后，请确保该人实际上在改进她的代码。在某些情况下，开发人员认为在实际会议结束时代码审查也会结束。他们离开并返回其新功能，尝试将您与他们共享的内容仅用于新代码。拥有一个体面的代码审查跟踪工具会有所帮助。
请注意，与您在公司中的特定角色和与其他人相比的专业知识无关，您的代码也应接受审核。您也不应该是唯一查看他人代码的人。
在我担任技术主管的最近一个项目中，我很难向同事解释说，对彼此的代码（包括我的代码）进行审查是他们的职责。一旦找到代码中的第一个问题，对即将审核其技术负责人代码的实习生的恐惧就消失了，而我们中间谁编写的代码无懈可击？
训练
代码审查是教与学编程和软件设计某些方面的绝佳机会，但其他方面则需要培训。
如果您能够培训您的同事，那就去做。如果您的管理层对培训的想法怀有敌意，请非正式地进行。我以非正式会议的形式进行了此类培训课程，有时甚至只是简单的讨论，有时会被管理层打断，以后再讨论。
除了直接培训之外，请确保您对麦康纳尔的Code Complete之类的书了解得足够多，并与同事讨论这些书。建议他们阅读开源项目的源代码，并为他们提供高质量代码的特定示例。而且，显然，您自己可以编写高质量的代码。
专注于背景，而不是人
我如何解决这种情况而不仅仅是关注“糟糕的公司文化”，“缺乏经验的毕业生”等。
这些毕业生的目标是：获得经验，学习知识，变得更加熟练。如果他们年复一年编写糟糕的代码并且对编程一无所知，那可能是因为您的团队或您的公司没有给他们这个机会。
如果您关注的是团队中没有毕业生的事实，那将无济于事。相反，请专注于为他们以及与他们一起可以做什么。代码审查和培训是改善情况的两种技术。
糟糕的公司文化是另一种野兽。有时可以更改。有时，它不能。在任何情况下，请记住您是该公司的一部分，因此您是公司文化的一部分。如果您无法更改它，或早或晚发现其本质上不好，则必须离开。
正确制定指标
您现在如何准确地测量代码？您是否衡量每个开发人员每天的提交次数？还是每个程序员每个月的KLOC？还是代码覆盖率？还是发现并修复了许多错误？还是回归测试发现的潜在错误数量？还是Continuous Deployment服务器完成的还原次数？
您衡量的事情很重要，因为团队成员正在使他们的工作适应所衡量的因素。例如，在几年前我必须工作的一家公司中，唯一可以衡量的是一个人在办公室花费的时间。不用说，这并不鼓励提供更好的代码，或者更聪明地工作，或者……好吧，根本无法工作。
弄清楚正面和负面的加强并随着时间的推移调整测量的因素实际上是您对团队成员的影响。如果正确完成，则可以实现简单的层次结构无法实现的结果。
困扰您的事情，使它们可以衡量。测量它们，并将结果公开。然后与其他团队成员一起改善结果。
例如，让我们考虑团队成员在类，类成员和变量的名称中犯了太多的拼写错误。真烦人 您如何衡量？使用解析器，您可以从代码中提取所有单词，然后使用拼写检查器确定包含错误和错别字的单词的比例，即16.7％。
下一步是与您的团队就目标比率达成一致。下一次冲刺可能是15％，下一次冲刺可能是10％，六周内为5％，两个月内为0％。这些指标将在每次提交时自动重新计算，并显示在办公室的大屏幕上。
如果您没有达到目标比例，您的团队可能会决定花更多的时间来解决拼写错误。或者您的团队可能会认为最好计算每个开发人员的比率，并在大屏幕上显示此信息。否则您的团队可能会发现目标过于乐观，因此您应该对其进行审查。
如果达到目标比例，下一步就是确保错误和错别字的数量不会随着时间的推移而增加。为此，您可以在构建中创建另一个任务，该任务检查拼写错误，如果发现至少一个错误，则使构建失败。现在您已经摆脱了这个问题，可以重新使用大屏幕来显示新的相关统计信息。
结论
我相信，您问题中提到的每个方面都可以通过我在回答中包括的技术来解决：
当其他开发人员加入该项目时，我注意到他们使用了不同的编码样式（有时是完全不同的样式）
您必须在提交时自动实施样式。
并且通常不使用属性访问器之类的现代语言功能（这在Objective-C中相对较新）。
这两个代码审查和培训来这里是为了转移你的语言知识。
有时他们会发明自己的自行车，而不是使用框架的类似功能
这两个代码审查和培训来这里是为了转移你的框架的知识。
或将其他编程语言的概念或从他们那里学到的模式转移到我们的代码库中。
这是一件好事。似乎是您向他们学习的机会。
通常，由于英语不好，他们无法正确命名方法或变量
代码审查还应侧重于正确的命名。一些IDE也具有拼写检查器。
有时候，我认为如果不是针对IDE，我认为他们会编写所有代码而没有缩进或格式化。
当然可以。风格很无聊，应该自动化。
基本上，我讨厌他们编写的代码。
请记住，在代码审查部分中：“目标不是显示开发人员有多糟糕。目标是提供改进的机会。”
它的格式/组织不好，有时与项目的其余部分完全不同。
自动样式检查。
当他们把意大利面条加到我的艺术品上时，我感到非常沮丧
等等，什么？艺术品吗？你猜怎么了？有些人（包括六个月内的您在内）可能会发现您的代码远非一件艺术品。同时，请务必理解，将您的作品视为艺术品，而将其视为垃圾作品不会帮助任何人。包括你。
感觉越来越像他们不被学习或不在乎的困扰：他们只是按照他们的要求去回家。
当然，他们会按照他们的要求去做。请记住：情境而非人员，并正确制定指标。如果情境要求他们做到最好，那么他们会做到的。如果上下文需要每月产生尽可能多的KLOC，仅此而已，那么他们也将这样做。