关闭。这个问题是基于意见的。它目前不接受答案。
**想改进这个问题吗?**更新这个问题,这样就可以通过编辑这篇文章用事实和引文来回答。
四年前关门了。
改进这个问题
我们的团队最近继承了非常混乱的代码。
因此,我的团队负责人决定在保存文件之前强制执行自动格式化代码的策略。我们甚至在eclipse(我们选择的ide)中找到了一个选项,在每次保存操作之前自动格式化代码。
就我个人而言,我反对它,因为我认为正确的编码可以防止混乱的代码(大多数时候),而自动格式化并不意味着正确的编码。
你有什么看法?
关闭。这个问题是基于意见的。它目前不接受答案。
**想改进这个问题吗?**更新这个问题,这样就可以通过编辑这篇文章用事实和引文来回答。
四年前关门了。
改进这个问题
我们的团队最近继承了非常混乱的代码。
因此,我的团队负责人决定在保存文件之前强制执行自动格式化代码的策略。我们甚至在eclipse(我们选择的ide)中找到了一个选项,在每次保存操作之前自动格式化代码。
就我个人而言,我反对它,因为我认为正确的编码可以防止混乱的代码(大多数时候),而自动格式化并不意味着正确的编码。
你有什么看法?
12条答案
按热度按时间rbl8hiat1#
在你的职业生涯中,你将被要求遵循每个公司的标准。这意味着很多时候你可能不同意这项政策。
抱怨必须使用公司标准进行自动格式化是不专业的,而且最终会损害老板和上级对你的看法,因为他们会认为你不是一个团队合作者。你会习惯于任何标准的格式,不管它离你想要的有多远,总有一天当你是经理的时候,你可以选择如何格式化。同时,这不是你的决定(你没有代码库,公司有),你需要做你被要求做的事情。
如果你有一些关于自动套用格式如何使代码更难阅读的有效例子,你可以和你的老板分享,但老实说,这是一场你不可能赢的战斗,它只会让你看起来不好尝试。
ttcibm8c2#
我认为你的代码格式很重要。虽然我会用这个例子来论证总是使用大括号,但给出的例子确实突出了像这样的愚蠢错误潜入的可能性!
我发现在查看具有各种不同格式的源文件时,您必须更加努力地理解代码。规则的代码模式更容易理解语义,因为语句都“在正确的位置”。
我不确定“适当的编码”是什么意思,因为它似乎有点含糊不清,什么是“适当的”。有些语言结构可能永远不会在正常情况下使用,有些软件工程反模式应该避免。如果这些东西是正确编码的意思,那么确保这些东西是重要的,但它们不会反映在源文件文档的格式上。
有一些工具可以通过违反格式化生成失败来强制源文件中的代码格式化。一开始,我对这些工具持怀疑态度,因为它们看起来有点苛刻,但我发现,让代码的结构保持一致,可以真正提高生产率。
p、 最后一句话完全是传闻,因为我没有标准来支持它。
56lgkhnf3#
在这件事上,我和你们的组长意见一致,我有两条建议:
将每个文件保存一次,其中唯一的更改是格式,并使用一条提交消息反映所有更改,然后返回并进行实际的代码更改。当您需要进行不同的更改时,这将节省大量时间。格式修订版几乎会更改每一行代码,因此几乎不可能在同一修订版上找到真正的更改。
商定一个编码标准并定制eclipse的自动格式化工具以遵循该标准。
yi0zb3m44#
在我看来,一致的代码格式提高了易读性。它显然不能代替好的代码,但另一方面,格式松散的最优秀的结构也不能称为好代码。
对我来说,自动格式化的问题主要是它干扰了版本控制系统。但是,格式的一次性转换(无需任何其他更改)可能会很好地改进工作流。
pbossiut5#
在eclipse中启用自动格式化,我能想到的一个问题是,如果您使用源代码管理(您使用的是源代码管理,对吧?),差异将是巨大的,并且可能很难解释什么是真正的代码更改,而不是格式更改。
也就是说,拥有格式良好的代码是编写可靠软件的关键。
wd2eg0qa6#
实际上,我们在eclipse中使用自动格式化,它通常会降低代码的可读性,例如插入许多换行符。当我们迁移到一个新的eclipse版本时,虽然我们使用了相同的设置,但格式是不一样的。与版本控制系统相结合,这是一个巨大的缺点。我更喜欢checkstyle插件来实现一致的代码风格。
但正如我所说,在重构文件时,我只会使用一次自动格式化。
3pvhb19x7#
i、 作为开发团队负责人,我反对自动格式化。因为可读的代码很重要,所以负责任的开发人员可以在他们认为必要的时候格式化他们的代码是很重要的。自动格式化程序可以破坏精心编制的注解,它们将删除为清晰起见插入的额外空行,等等。
我们使用像checkstyle这样的插件,它有一个必须遵守的标准规则集,签入的代码应该没有checkstyle警告。如果出现一些非结构化代码,eclipse格式化程序可以进行第一次清理和checkstyle,而friends会指出需要解决的问题。
xkrw2x1b8#
在提交代码时,一致的代码格式确实有助于进行差异化等操作。
我已经将我的源代码管理脚本配置为推送时自动格式化为“内部样式”,拉送时自动格式化为我喜欢的样式,所以每个人都很高兴。
我建议你也考虑一下。
pdsfdshx9#
取决于你所说的“无组织”是什么意思。我们说的是风格上的不一致,还是班级结构是一个难以理解的霍奇·波奇?如果你是通过自动格式化程序来处理的话,我猜是前者。
“适当的编码”并不一定意味着“开发人员之间的一致性”。如果我的编辑器设置为四个空格硬标签,而你的编辑器设置为三个空格软标签,那么我们两个工作的代码看起来都会很糟糕(而且我们的项目经理可能会让我们两个都头晕目眩,让我们知道我们应该使用什么标准)
自动格式化程序是一个蛮力解决方案,几乎可以保证偶尔会把一些不寻常但完全可读的东西变成一团糟。如果代码真的那么混乱,那么这是一个合理的起点。但是,一旦您自动格式化了大量从已有代码中吸取的内容,您最好建立团队首选的样式约定并从那里开始。
mm5n2pyu10#
格式化代码非常重要:
通过使代码保持适当的缩进,用户可以更容易地在中型或大型文件之间导航。
通过在所有项目中保持一致的编码风格,当人们转到其他项目时,他们将更加熟悉代码。当然,这也与编码准则、如何命名变量等有关,这些也应该在一个共同点上相对规范化。
如果您花一些时间来制定正确的代码格式规则,那么您还可以保证代码可以被更多的用户查看(不幸的是,我不得不在文本中手工编辑代码很多次[想想记事本或emacs]。通过将行长度设置为80列左右,这会有所帮助)
最重要的是,通过保持格式一致,您可以更轻松地区分两个文件
ehxuflar11#
我不同意你的意见。对我来说,格式化,即使只是“呈现”源代码的一种方式,也是一个重要的代码质量指标。
使用自动格式化有几个优点。它在团队的所有开发人员中统一了格式。这将避免您在scm操作中遇到一些麻烦:例如,合并两个几乎没有实际更改但格式差异很大的文件是一场噩梦!
它还可以显示一些错误。例如:
将重新格式化:
显示第二行不在
if
声明。最后,但并非最不重要的是,格式良好的代码(不仅适用于java)更易于阅读!
flmtquvp12#
只自动格式化一次继承的代码,然后不自动格式化继续。