您如何编码而不冒犯？

我的意思是，您如何着手与已经使用多年并且非常熟悉它的开发人员共享代码库？

我不想踩任何人的脚，但是我对操作方式的抱怨不是那么微妙，无论是我用空白代码还是频繁检入SVN。因此，尽管我可以轻松更改这些内容，但总体而言，我想成为一个更好的团队开发人员。

除了询问外，我不确定该怎么做，但也许你们有一些想法可以付诸实践。

更新

没有任何样式指南可以说，只是人们不习惯共享代码库。每个人都有自己的孤立的代码世界。

这是一家Perl商店，但是我敢肯定，这适用于任何语言

更新2

后来成为首席执行官的CTO完全是大狂，是这些投诉的主要来源。如果您没有按照他的喜好来做任何事情，无论是使用Mac还是Emacs，或者使用4个制表符而不是2，或者以某种方式修饰，那您就很自卑。我试图纠正这种可怕的情况，但是对我来说唯一正确的答案就是离开。

我坚信这是在工作场所中欺负的一个例子，随后，我更加意识到在工作环境中可能存在细微的欺凌和不当行为。

对于寻求此类情况答案的任何开发人员，请立即离开。您不能通过团队合作来摆脱糟糕的团队环境。

问。就是说，问问你一起工作的人。尽最大努力坚持现有代码的既定样式。尤其要询问是否有编码标准的文档列表，并遵循它。如果没有，请根据您在代码中观察到的内容写一份初稿，然后请其他团队成员对其进行评论。您将开始记录公认的编码做法，从而为公司（以及后来的新开发人员）提供服务。如果事实证明老朋友在可接受或不可接受的问题上彼此意见不一致，则唯一的风险可能是陷入中间。

另外，不要害怕 做你自己。您可能是新手，但您是团队的一员，您的观点是有效的。如果您能想到做某事的更好方法，请提出建议。尊重其他团队成员和行事方式，但不要让他们推动您前进。如果公司不重视您的投入，就不会雇用您。

如果您可以在团队中找到一个看起来很友善的人，将会很有帮助并且特别愿意回答问题的人，将会很有帮助。（如果这是一支优秀的团队，那么应该是每个人，但是团队并不总是这样。）您的老板可能已经指派了一个人来帮助您入门。使用该人作为资源。写下您遇到的问题，然后不时要求有帮助的人回答。

至于“经常检查”代码，为什么不为定期提交创建自己的分支，然后在代码准备就绪时合并回主干？这样做对其他任何人都没有伤害，并且当您的同事看到您从他们想要的SVN中获得收益时，他们可能会跟随您。

关于空格：只需执行即可，但是代码已经做到了。顺其自然。

关于SVN签入：非常清楚地记录下来。这可以帮助人们了解代码中正在发生的事情。（后续：他们对经常签到有何异议？）

通常：开始建立编码标准文档。不要试图用100条规则填充它。只需添加规则即可。

另外：向其他开发人员提出问题。这使他们有机会在做他们不喜欢的事情之前先权衡一下。另外，它可以建立关系。此外，您还可以了解有关商店运作方式的更多信息。

至于代码格式样式（空格，制表符，大括号等），您应该遵循代码中流行的标准。如果没有，我认为他们没有什么可抱怨的。归根结底，无论您是否将花括号放在自己的行上，在方法参数列表周围放置空格等都是个人喜好，并且应该屈从于主流风格，因为从长远来看，它实际上并不会物。重要的是保持一致。

在将代码检入SVN时，我会尝试传布我认为做事的正确方法，而不是让自己陷入困境。除非它可以生成并通过测试，否则我不会签入我的代码，并且如果我进行了几个不相关的更改，我会将工作分解为几个提交。如果有一段时间会出现问题，我创建一个分支并在那里做我的工作。提交得到描述性评论。根据我的经验，这种方法比“在周五5:00进行大量检查”更有效，并且根据我在这里和其他地方所读到的大部分内容，这似乎是流行的“最佳实践”。

首先阅读他们的编码约定文档（如果他们没有，请要求他们写一个，以便您可以遵循）

然后注意并做出有意识的努力，以遵循他们说的话。在您看来，它们很苛刻，但编码标准很重要，最好指出现在出了什么问题，而不是等到以后进行较大的更改时再发展为问题。

我确定当新手踩脚时，您会在一两年内完成相同的操作:)

要求公司代码标准。更注重细节。如果您看到其他人遵循非常特殊的空格和括号模式形式，请遵循它们。作为高级人员，您可能会认为这有些挑剔，但是作为项目的初中或新手，您需要证明自己可以跟随才能开始。

另外，请了解，项目上的任何新开发人员确实都会有必要的 “准备”时间。因此，不必为此担心。

您能做的最好的事情就是听从他们给您的建议。无法提前告知他们想要什么。除非你通灵。

但是，我建议当人们给您建议时，请记录在案。你有维基吗？如果是这样，请使用它。如果没有，那么使用源代码签入的文本文件可能是一个好主意。编写井井有条的编程指南。它可以帮助您记住操作方法，如果有人与您之前的建议相抵触，它可以为您讨论不一致之处提供参考。另外，当下一个人加入团队时，他们不必经历您正在经历的一切。

我建议您不要将文档中的建议归因于个人（因此“代码块应以三个空格缩进”，而不是“比尔告诉我代码块应以三个空格缩进”）。但是，如果您可以以不干扰他人的方式记录该信息（例如，在提交注释中，编写“根据Bill的建议添加有关缩进的规则”），那么它可能会有助于解决矛盾，因为您可以立即获得两种观点在某事上。实际上，我在想的是，如果您得到相互矛盾的建议，则需要避免成为两位不同意某事的同事踢足球。这有点掩饰您的做法，但这可能是审慎的做法。

一个简单的方法就是找到样式指南并遵循它。大多数人都没有太过冒犯性，会阻止您冒犯他人。