I disagree with you. For me, the formatting, even if it is only a way to "present" the source code, is also an important code quality indicator.
Using the auto-formatting has several advantages. It homogenizes the format among all the developers of the team. This will avoid you some troubles with the SCM manipulation: for example, merging two files that have few real changes, but a lot of formatting differences is a nightmare!
It can also show you some errors. For example:
if (aCondition)
foo();
bar();
will be reformatted:
if (condition)
foo();
bar();
showing that the second line is not in the if statement.
Last, but not least, a well formatted code (not only for Java) is easier to read!
In my opinion consistent code formatting improves legibility. It is clearly no substitute for good code, but on the other hand the most brilliant construct which is sloppily formatted can also not be called good code.
The problem with auto-format for me is mostly that it disturbs the versioning system. A one-time conversion of formatting - without any other changes - may however well improve the workflow.
A consistent code formatting really assists with diffing and such when submitting code.
I've configured my source control scripts to auto-format to 'house style' when pushing and auto-format to my preferred style when pulling, so everybody is happy.
I'm with your team leader on this one, and I have two suggestions for you:
Save each file once where the only change is the formatting with a commit message that reflects that this was all that changed, then go back and make your actual code changes. This will save you a lot of time when you need to diff changes. The format revision will have nearly every line of code changed, so it will be practically impossible to find a real change on the same revision.
Agree upon a coding standard and customize Eclipse's auto-format tool to follow that standard.
We are actually using auto-formating in eclipse and often it makes my code less readable, for example by inserting to many line breaks. And as we migrated to a new eclipse version, the format was not the same although we used the same settings. That is a huge disadvantage in combination with a version control system. I prefer the CheckStyle-plugin to achieve a consistent code style.
But as said I would use autoformatting once when refactoring a file.
Depends on what you mean by "disorganized." Are we talking about stylistic inconsistencies, or is the class structure an unintelligible hodge-podge? I'm guessing the former if you're addressing it through an auto-formatter.
"Proper coding" doesn't necessarily mean "consistent across developers". If I have my editor set to four-space hard tabs and you have yours set to three-space soft tabs, code we both work on is going to look like ass. (And our project manager should probably thwack us both upside the head and let us know what standard we SHOULD be using.)
The auto-formatter is a bit of a brute force solution and is pretty much guaranteed to occasionally turn something unusual but perfectly readable into a mess. If the code is really that much of a mess, it's a sensible starting point. But once you've auto-formatted the bulk of the Suck out of the pre-existing code, you're better off establishing the team's preferred style conventions and proceeding from there.
I, as a development team lead, am against automatic formatting. Because readable code is important, it is important that responsible developers can format their code as they see necessary. Automatic Formatters can ruin carefully crafted comments, they will get rid of extra blank lines inserted for clarity, etc.
We use plugins like checkstyle with a standard ruleset that has to be adhered to, checked in code should have no checkstyle warnings. If some unstructured code comes along, the eclipse formatter can do the first cleanup and checkstyle and friends point to the issues left to resolve.
I think the format of your code is important. The examples given do highlight the potential for silly errors like that to creep in, although I would use the example to argue for always using the braces!
I find you have to work harder to understand code when looking at source files which have a variety of different formatting. Regular code patterns make it easier to understand the semantics because the statements are all "in the right place".
I am not sure what was meant by "proper coding" as it seems a little ambiguous as to what constitutes "proper". There are language constructs which should probably never be used in normal circumstances and software engineering anti-patterns that should be avoided. If these things are what is meant by proper coding then sure these things are important but they do not reflect on the formatting of the source file document.
There are tools out there to force code formatting within a source file by making violations of the formatting build failures. At first I was sceptical of such tools as they seem a little draconian but I have found that having the structure of code uniform a real productivity boost.
P.S. Last statement completely anecdotal as I have no metrics to back it up.
The one problem I can think of with enabling auto-formatting in Eclipse is that if you are using source control (you ARE using source control, right?), the diffs will be massive and it will make it possibly difficult to decipher what was a real code change versus a format change.
That being said, having well formatted code is critical to writing solid software.
By keeping the code properly indented, navigation across medium or large files can be easier on the user.
By keeping a constistent coding style across all projects, when people move to other projects they will be more familiarized with the code. Of course, this is also related to coding guidelines, how to name variables, etc which should be also relatively normalized in a common ground.
If you spend some time doing proper code formatting rules, you also guarantee that the code can be viewed by more users (I had to edit code by hand in a text [think notepad or emacs] by hand many times, unfortunately. By setting a row length to 80 cols or so it can help)
Most importantly, by keeping formatting consistent you can diff two files much more easier
In your career, you will be expected to follow the standards of each individual company. That means that much of the time you may not agree with the policy.
To whine about having to use a company standard for auto-formatting is unprofessional and ultimately bad for the way your boss and higher-ups view you as they will think you are not a team player. You will get used to whatever the standard formatting is no matter how far it is from what you would like and someday when you are the manager, you can choose how the formatting will be done. In the meantime, it isn't your call (you don't own the code base, the company does) and you need to do what you were asked to do.
If you have some valid examples of how the autoformat makes the code harder to read, you can share them with your boss, but honestly, this is a fight you are unlikely to win and it just makes you look bad to try.
发布评论
评论（12）
我不同意你的观点。对我来说，格式化，即使只是“呈现”源代码的一种方式，也是一个重要的代码质量指标。
使用自动格式化有几个优点。它使团队中所有开发人员的格式同质化。这将避免您在 SCM 操作方面遇到一些麻烦：例如，合并两个几乎没有实际更改但存在大量格式差异的文件是一场噩梦！
它还可以向您显示一些错误。例如：
将被重新格式化：
显示第二行不是在
if语句中。最后但并非最不重要的一点是，格式良好的代码（不仅适用于 Java）更易于阅读！
I disagree with you. For me, the formatting, even if it is only a way to "present" the source code, is also an important code quality indicator.
Using the auto-formatting has several advantages. It homogenizes the format among all the developers of the team. This will avoid you some troubles with the SCM manipulation: for example, merging two files that have few real changes, but a lot of formatting differences is a nightmare!
It can also show you some errors. For example:
will be reformatted:
showing that the second line is not in the
ifstatement.Last, but not least, a well formatted code (not only for Java) is easier to read!
仅自动格式化继承的代码一次，然后继续而不进行自动格式化。
Auto-format the inherited code just once, and then proceed without auto-formatting.
在我看来，一致的代码格式可以提高可读性。它显然不能替代好的代码，但另一方面，即使是最出色的构造，如果格式不规范，也不能称为好的代码。
对我来说，自动格式化的问题主要是它会干扰版本控制系统。然而，一次性格式转换（无需任何其他更改）可能会很好地改善工作流程。
In my opinion consistent code formatting improves legibility. It is clearly no substitute for good code, but on the other hand the most brilliant construct which is sloppily formatted can also not be called good code.
The problem with auto-format for me is mostly that it disturbs the versioning system. A one-time conversion of formatting - without any other changes - may however well improve the workflow.
一致的代码格式确实有助于提交代码时进行比较等。
我已将源代码控制脚本配置为在推送时自动格式化为“内部风格”，在拉取时自动格式化为我喜欢的风格，所以每个人都很高兴。
我建议你也考虑一下。
A consistent code formatting really assists with diffing and such when submitting code.
I've configured my source control scripts to auto-format to 'house style' when pushing and auto-format to my preferred style when pulling, so everybody is happy.
I'd recommend you consider the same.
我同意你的团队负责人的意见，我有两个建议给你：
将每个文件保存一次，其中唯一的位置是
更改是格式化
提交反映这一点的消息
这就是全部改变，然后走吧
返回并编写您的实际代码
变化。这将为您节省很多
当你需要比较的时候
变化。格式修订将
几乎每一行代码都有
改变了，所以实际上会是
不可能找到真正的改变
相同的修订版。
就编码标准达成一致并
自定义 Eclipse 的自动格式化工具
遵循该标准。
I'm with your team leader on this one, and I have two suggestions for you:
Save each file once where the only
change is the formatting with a
commit message that reflects that
this was all that changed, then go
back and make your actual code
changes. This will save you a lot
of time when you need to diff
changes. The format revision will
have nearly every line of code
changed, so it will be practically
impossible to find a real change on
the same revision.
Agree upon a coding standard and
customize Eclipse's auto-format tool
to follow that standard.
我们实际上在 Eclipse 中使用自动格式化，这通常会降低我的代码的可读性，例如插入许多换行符。当我们迁移到新的 Eclipse 版本时，尽管我们使用了相同的设置，但格式并不相同。与版本控制系统结合使用时，这是一个巨大的缺点。我更喜欢使用 CheckStyle 插件来实现一致的代码风格。
但正如我所说，我会在重构文件时使用一次自动格式化。
We are actually using auto-formating in eclipse and often it makes my code less readable, for example by inserting to many line breaks. And as we migrated to a new eclipse version, the format was not the same although we used the same settings. That is a huge disadvantage in combination with a version control system. I prefer the CheckStyle-plugin to achieve a consistent code style.
But as said I would use autoformatting once when refactoring a file.
取决于你所说的“无组织”是什么意思。我们是在谈论风格上的不一致，还是阶级结构是一个难以理解的大杂烩？如果您通过自动格式化程序来解决它，我猜是前者。
“正确的编码”并不一定意味着“开发人员之间保持一致”。如果我将我的编辑器设置为四空格硬选项卡，而你将你的编辑器设置为三空格软选项卡，那么我们共同处理的代码将会看起来很糟糕。 （我们的项目经理可能应该狠狠地敲打我们俩的头，让我们知道我们应该使用什么标准。）
自动格式化程序是一个有点强力的解决方案，并且几乎可以保证偶尔会变成一些不寻常但完全可读的东西陷入混乱。如果代码真的那么混乱，那么这是一个明智的起点。但是，一旦您从预先存在的代码中自动格式化了大部分 Suck 内容，您最好建立团队首选的样式约定并从那里开始。
Depends on what you mean by "disorganized." Are we talking about stylistic inconsistencies, or is the class structure an unintelligible hodge-podge? I'm guessing the former if you're addressing it through an auto-formatter.
"Proper coding" doesn't necessarily mean "consistent across developers". If I have my editor set to four-space hard tabs and you have yours set to three-space soft tabs, code we both work on is going to look like ass. (And our project manager should probably thwack us both upside the head and let us know what standard we SHOULD be using.)
The auto-formatter is a bit of a brute force solution and is pretty much guaranteed to occasionally turn something unusual but perfectly readable into a mess. If the code is really that much of a mess, it's a sensible starting point. But once you've auto-formatted the bulk of the Suck out of the pre-existing code, you're better off establishing the team's preferred style conventions and proceeding from there.
作为开发团队负责人，我反对自动格式化。因为可读的代码很重要，所以负责任的开发人员可以根据需要格式化他们的代码，这一点很重要。自动格式化程序可能会破坏精心设计的注释，它们会删除为了清晰起见而插入的额外空白行等。
我们使用 checkstyle 等插件，并必须遵守标准规则集，签入的代码不应有 checkstyle 警告。如果出现一些非结构化代码，Eclipse 格式化程序可以进行第一次清理并检查样式，朋友们会指出剩下的问题需要解决。
I, as a development team lead, am against automatic formatting. Because readable code is important, it is important that responsible developers can format their code as they see necessary. Automatic Formatters can ruin carefully crafted comments, they will get rid of extra blank lines inserted for clarity, etc.
We use plugins like checkstyle with a standard ruleset that has to be adhered to, checked in code should have no checkstyle warnings. If some unstructured code comes along, the eclipse formatter can do the first cleanup and checkstyle and friends point to the issues left to resolve.
我认为代码的格式很重要。给出的例子确实强调了出现类似愚蠢错误的可能性，尽管我会用这个例子来争论总是使用大括号！
我发现在查看具有各种不同格式的源文件时，您必须更加努力地理解代码。常规代码模式使理解语义变得更容易，因为语句都“在正确的位置”。
我不确定“正确编码”是什么意思，因为“正确”的构成似乎有点含糊。有些语言结构在正常情况下可能永远不应该使用，而软件工程反模式则应该避免。如果这些事情就是正确编码的含义，那么这些事情肯定很重要，但它们不会反映源文件文档的格式。
有一些工具可以通过违反格式化构建失败来强制对源文件进行代码格式化。起初，我对此类工具持怀疑态度，因为它们看起来有点严厉，但我发现，统一的代码结构确实可以提高生产力。
PS 最后的陈述完全是轶事，因为我没有指标来支持它。
I think the format of your code is important. The examples given do highlight the potential for silly errors like that to creep in, although I would use the example to argue for always using the braces!
I find you have to work harder to understand code when looking at source files which have a variety of different formatting. Regular code patterns make it easier to understand the semantics because the statements are all "in the right place".
I am not sure what was meant by "proper coding" as it seems a little ambiguous as to what constitutes "proper". There are language constructs which should probably never be used in normal circumstances and software engineering anti-patterns that should be avoided. If these things are what is meant by proper coding then sure these things are important but they do not reflect on the formatting of the source file document.
There are tools out there to force code formatting within a source file by making violations of the formatting build failures. At first I was sceptical of such tools as they seem a little draconian but I have found that having the structure of code uniform a real productivity boost.
P.S. Last statement completely anecdotal as I have no metrics to back it up.
我能想到的在 Eclipse 中启用自动格式化的一个问题是，如果您使用源代码管理（您正在使用源代码管理，对吧？），差异将会很大，并且可能很难破译什么是源代码管理。真正的代码更改与格式更改。
话虽如此，拥有格式良好的代码对于编写可靠的软件至关重要。
The one problem I can think of with enabling auto-formatting in Eclipse is that if you are using source control (you ARE using source control, right?), the diffs will be massive and it will make it possibly difficult to decipher what was a real code change versus a format change.
That being said, having well formatted code is critical to writing solid software.
格式化代码非常重要：
Formatting code is extremely important:
在您的职业生涯中，您将需要遵循每个公司的标准。这意味着很多时候您可能不同意该政策。
抱怨必须使用公司自动格式化标准是不专业的，最终也不利于你的老板和上级对你的看法，因为他们会认为你不是一个团队合作者。您将习惯任何标准格式，无论它与您想要的格式有多远，有一天当您成为经理时，您可以选择如何完成格式设置。与此同时，这不是你的决定（你不拥有代码库，公司拥有），你需要做你被要求做的事情。
如果您有一些关于自动格式如何使代码更难阅读的有效示例，您可以与您的老板分享它们，但说实话，这是一场您不太可能获胜的战斗，而且只会让您看起来很难尝试。
In your career, you will be expected to follow the standards of each individual company. That means that much of the time you may not agree with the policy.
To whine about having to use a company standard for auto-formatting is unprofessional and ultimately bad for the way your boss and higher-ups view you as they will think you are not a team player. You will get used to whatever the standard formatting is no matter how far it is from what you would like and someday when you are the manager, you can choose how the formatting will be done. In the meantime, it isn't your call (you don't own the code base, the company does) and you need to do what you were asked to do.
If you have some valid examples of how the autoformat makes the code harder to read, you can share them with your boss, but honestly, this is a fight you are unlikely to win and it just makes you look bad to try.