如果可以在源代码控制提交、签出、差异等之前和之后自动格式化代码,那么公司真的需要标准的代码风格吗?
感觉就像自编程开始以来一直在激烈的标准编码风格辩论,例如“将括号放在下一行”或“正确缩进你的 (”不再重要。
我意识到在空格很重要的语言中,差异必须考虑它,但是对于风格是个人喜好的语言,真的需要再担心了吗?
如果可以在源代码控制提交、签出、差异等之前和之后自动格式化代码,那么公司真的需要标准的代码风格吗?
感觉就像自编程开始以来一直在激烈的标准编码风格辩论,例如“将括号放在下一行”或“正确缩进你的 (”不再重要。
我意识到在空格很重要的语言中,差异必须考虑它,但是对于风格是个人喜好的语言,真的需要再担心了吗?
自动格式化实际上只能处理空白。
它不会解决给变量提供奇怪无意义名称的开发人员。它不会解决一些开发人员在错误和抛出异常时函数返回 null 的问题。
我相信其他人可以想到更多的例子。
这就是我们在工作中所做的:
我们都使用 Eclipse。我们没有使用 Eclipse 的政策,但不知何故,我们都不是 IDEA/IntelliJ 人。我们还认为我们的代码在编写时应该考虑到遗留问题。这意味着我们的代码必须在 ( #1 )几年后以某种方式可读,无论是谁编写的,也不管那个人是否已经在公司了。
Eclipse 有几个方便的特性,保存时自动格式化和一个特定的格式化工具。从链接的屏幕截图中可以看出,它可以使用 XML 进行配置。因此,我们公司的每个员工都可以使用一堆预制的 XML:所以当一个新人进来时,我们会引导他完成整个过程并为他们配置他们的 Eclipse(是的,这样做有点邪恶)所以它实际上使用了我们提供的那些格式化 XML:s。我们不强制保存时自动格式化,我们不想完全侵入,我们只想将我们所有的开发人员推向正确的方向。为了提高兼容性,我们主要使用JCC中定义的规则。
接下来是重要的部分,实际构建。我们喜欢自动构建,为此我们使用Hudson 持续集成服务器。除此之外,我们的配置中还有两个重要部分:
Checkstyle 插件是我们代码风格实施指南中的魔术师:
基本上这意味着当任何人将丑陋的代码提交到我们的 CVS 中时,我们的构建服务器会自动降低该人的分数。
这意味着最终我们中的任何一个人都可以根据外观和 OO 原则(例如德米特法则、圈复杂度等)的一般代码质量在排行榜上排名。当然这不是一个完全严肃的统计数据,但它是一个很好的迹象表明你在我们的 CI 中启动构建时做错了,这不会降低你的分数——我们的大多数提交的价值在 1 到 5 分之间。
它有效吗?某种程度上,我认为我们工作中的任何人都不会编写丑陋或无法维护的代码,而且我个人喜欢寻找各种分数,所以这绝对激励我编写看起来不错的代码并遵循我所知道的所有 OO 范例。
作为一家公司,我们真的需要它吗?我认为我们所做的正如您在阅读整个答案时应该看到的那样,它可以被认为是它带来的进步的良好实践。
#1
:在相关说明中,我从 2002 年开始重构了使用这些标准的遗留代码,即使在其原始形式中看起来也一点也不“糟糕”,在新形式中当然也不会更糟
不,不是。
如果您实际上可以使其始终如一地工作并且没有使其标记代码由于不同的代码布局风格而发生了变化。
然而,这只是编码标准的一小部分。它不会涵盖多个返回语句,三元运算符的使用与否等。
如果商店使用的编码风格与开发工具所遵循的编码风格相同,那总是很好的。
否则,如果有大量代码已经遵循与工具不同的商店标准,您有两种选择:
许多商店都采用后者。无论如何,确实需要某种标准,并且确实需要遵循。
一些开发工具允许您调整它们的标准。在某些情况下,您可以使工具符合车间标准。
如果您可以确保团队中的每个人都能看到“正确”格式的源代码,无论他们认为是什么,这可能不再那么重要了。但是我还没有看到可以做到这一点的系统 - 你可以做它的一部分(例如,在签入/签出之前和之后重新格式化)但是现在你还必须考虑将 Web 界面纳入版本控制,外部代码审查系统直接与版本控制系统等交互。
标准代码风格的主要目的是(恕我直言)确保您可以轻松阅读其他团队成员的代码,而无需开始对其进行逆向工程,因为所有代码都是使用相同的指导原则编写的。缩进和括号的放置似乎是一个主要的问题,但它们只是一个非常小的问题,在我看来,有点夸大其词,而且对于使代码保持一致的需求来说并不是很重要的部分。
不幸的是,我不知道有任何工具可以自动将一致的编码原则应用于源代码......
是的,如果希望拥有同质的代码库,则需要编码风格。这样的代码库可用于防止个人拥有部分代码库的所有权,这可能会在人们离开团队时引起问题。如果你无法想象有完全不同的风格和理解这一切的问题,只要看看在各种通信中组织英语文本的所有不同方式,都是书面的,但完全不同,例如推文、电子邮件、短信、即时消息、留言板帖子等以及字体、大小写、装饰等的变化。