有没有一种方法可以支持开发团队中的不同编码风格

13

问题：两个开发人员=>对缩进有三点意见，是否在换行符上加上大括号等等。

我们通常在项目中与三到四个人一起工作，每个人都有自己的代码风格。我知道，常见的解决方案是在每个人都必须使用的代码风格上达成共识，但是我不想强迫有创造力的程序员穿着不适合他们的西装。

所以问题是：有没有办法让每个程序员都保持自己的风格，但是在存储库中有一个通用的代码库？我想到了一些git / svn / whatever插件，它们在签出和提交时在个人样式和通用样式之间变化。在我看来，此方法中的棘手部分是支持文件版本之间的正确差异

coding-style

— 凯
source

1

大多数语言都有自动代码格式化程序，但是对于某些语言（例如C ++），由于解析语言的复杂性，很难使其完全可靠。

— Joris Timmermans

5

真是个坏主意。让您的团队提出一个共识标准，然后让他们应用它。如果喝点酒，告诉他们长大一点。

— Clement Herreman

8

也许需要在这里做出另一个非常普通的评论：代码样式的差异是否存在实际问题？不要修复未损坏的东西！

— Joris Timmermans

5

“但是我不想强迫有创造力的程序员穿着不适合他们的西装”-如果您的程序员不能适应缩进或大括号样式更改等简单的事情，则需要雇用更好的开发人员。一旦使用一种新样式达一两个星期，您便会忘记它。

— Mike Weller 2013年

4

@MikeWeller不能相反吗？命名约定是我曾经考虑过的唯一重要的事情，因为它使在定义上下文之外更容易确定事物的目的。只要有人对块嵌套，开始和结束的位置进行半一致的样式化设计，我就永远不会理解为什么它应该这么重要。

— Erik Reppen

20

不，您需要制定一个标准。如果您有团队成员B更改（使用自动IDE工具或手动进行了更改），则代码团队成员A编写了整堆代码，这些更改将被提交并显示为更改。

这几乎是每个团队都面临的事情，因此，标准是“强制性的”。我建议您遵循语言权威标准作为基准，并采用它们以适合您的团队。

拥有一致的编码风格也将有助于项目的可维护性，并减少从事编码工作的新手的进入门槛。

— 山姆
source

11

不，您将需要定义一种编码标准（最好是已经存在的一种编码标准）并让您的开发人员遵守。成为专业程序员意味着您能够适应正在从事的项目中使用的任何编码标准。

— 杰斯珀
source

2

+1。让他们选择一个，但让他们应用它。

— Clement Herreman

我希望格式化是编程语言标准的一部分，这样程序不仅是“有效的”或“无效的”，而且还具有第三种状态，即“有效且格式正确”。

— JesperE

4

（或多或少）在python中是这样，缩进是一种语言语义。

— Clement Herreman

2

Go并非严格执行此操作，而是带有内置的源代码格式化程序go fmt。参见golangtutorials.blogspot.fr/2011/06/…–

— Clement Herreman

1

@JesperE这是用Python实现与PEP8和相应的工具，创造性地命名PEP8。

— phihag 2013年

8

是的，只要样式都合理，并且人们不会四处更改别人的代码以匹配他们的偏好和/或在一个代码文件中混合样式，它就可以工作。
这不是理想的选择，但是与继承旧代码创建到自己的不同“标准”并将其与代码库集成一样，这没有什么不同。
因此，如果必须这样做，请遵循以下准则：

无需更改样式不同的代码即可满足您的偏好，这会浪费时间并引入错误
在任何单个文件中保持一致。因此，如果最初使用样式A来编写它，那么每个人在修改它时都会使用样式A
确实为您的公共接口创建了一个通用标准，因此对于暴露给外部的所有内容（是的，系统的其他子组件都是外部的）。

— 温廷
source

2

我还要补充一点，专业开发人员通常总是倾向于融合彼此的样式。他们将在某些方面进行简短的非正式讨论并达成协议。

— Joris Timmermans

需要注意的是，将自动代码重新格式化的使用保持在最低限度（如果不是绝对禁止的话），效果很好。

— grahamparks 2013年

2

“不更改样式不同的代码来满足您的偏好，这会花费时间并引入错误”-恰恰相反-手动匹配非自动化标准非常浪费时间，运行代码格式化程序，将更改提交为“使用选项格式化-不管“，然后进行功能变化的速度要快得多。

— 皮特Kirkham的

我认为这个答案实际上可能错过了问题的“自动格式化”部分？

— Joris Timmermans 2013年

文件之间的各种样式比仅具有一致的样式要难得多。

— 安迪

4

最简洁的答案是不。

尽管在工作中尤其是在诸如软件开发之类的基于知识的工作中要重视意见，但是开发人员必须意识到，意见只是意见，而他们在这里编写软件并不是要争论哪种行缩进标准是最佳的。

标准文档的目标应该是强制/建议一套通用的编码标准/惯例，以解决

布局项目，例如制表符，缩进，使用{，（，
变量，对象和函数名称，即CamelCase，匈牙利表示法
异常处理如何/何时/在何处执行
代码注释。您是否总是参考设计文档，错误号等

标准文档有助于确保该代码易于阅读，维护和一致。

在原始开发人员离开公司几年后，在签入之前检查代码，调试其他人的代码或修改代码时，这是无价的。

通常，在创建编码标准文档时，我会查看所用语言的行业标准（C，C＃，SQL），使用最适当的标准，分发给最资深/有影响力的开发人员进行评论，并在适当时加入评论，然后释放文档。

— 武装
source

1

在实际操作中，许多商店都有一位通常是Old Hand或PrimaDonna的开发人员，他们似乎很乐于创建Formatting Holy Wars，以供其他人使用。专业==无论我怎么说。你们怎么说==非专业。然后它演变。我见过一些编码标准强制执行诸如“使用大量全局变量，从不创建新类，不惜一切代价避免面向对象的编程，永远不做任何更改”之类的大事。可悲的是，人们试图塞入所谓的“编码标准”的范围是没有限制的。

— 沃伦·P

4

从理论上讲，在将代码提交到版本控制系统之前，可以自动将其重新格式化。

但是，存在一个大问题：自动代码格式化工具并非100％可靠。因此，您实际上可以使用该系统在代码中引入问题。在我看来，这扼杀了这个主意。有功能的代码总是比样式正确的代码更重要！

如果项目是分开的，并且代码的大部分部分倾向于由单个程序员“拥有”，那么可以允许他们使用自己的样式（在合理的范围内）。但是，如果几个人经常处理同一段代码，则可能有必要强制实施样式。

这是关于Stack Overflow的类似讨论。

— 社区
source

2

在链接的讨论中也请注意已接受的答案！

— Joris Timmermans

1

如果您满足以下条件，单向自动重新格式化代码可能是一个可行的解决方案：

查找一个自动格式器，该格式器实际上可以用于您要实现的约定和您的编程语言。
可以预先提交，这样重新格式化就不会出现在与实际功能更改混在一起且无法区分的更改日志中。
设法使您的团队就应该采用哪种约定达成共识（因为通常来说，签出开发者的个人喜好并没有“退路”，至少我不知道）。

在许多情况下，这些都不是一件容易的事，因此请考虑在这里进行战斗！我已经看到团队为C＃/。NET项目成功完成了此任务，其中重新格式化已在开发人员的PC上进行，因此在某些情况下是可能的。

— 乔里斯·蒂默曼斯
source

1

绝对可以。关于不流汗小东西的全部。

唯一重要的标准是“保持更改与现有代码相同的样式”。只要您可以使自己适应不是您喜欢的编码样式，那么您就可以使用任何编码样式。

因此，在同一家公司中以3种不同的样式工作有什么大不了的。您的开发人员需要理解这一点，即可以按照自己喜欢的方式编写代码，但要为使用不同样式的其他文件进行更改后，他们必须保持该样式（否则看起来会很糟糕）。不允许重新格式化（否则它们将不断地重新格式化，而scm diff将无用）（如果执行此操作，则应使用自动格式化的格式）。

一旦有可能，他们会就使用哪种样式达成共识，或者在大多数情况下样式会一起漂移。如果他们对此很幼稚并且会一直重新格式化彼此的代码，那么该是时候从互联网上下载标准并要求他们使用它了。无论如何，您可能想要这样做，只是将它们作为“玩得好”的卡片摆在他们的脸上。

— gbjbaanb
source