如何让管理层相信重新格式化整个 Java 代码库是安全的
如何向管理层证明对大型代码库中的所有 .java 文件进行批量重新格式化（以使代码符合公司的编码标准）是安全的并且不会影响功能。
答案必须同时满足非技术人员和技术人员的需求。
编辑：2010-03-12对你们之间的技术进行澄清；重新格式化 = 仅空白更改 - 没有“组织导入”或“成员变量、方法等的重新排序”。
编辑：2010-03-12感谢您的多次回复。令我惊讶的是，这么多读者对 Mrjoltcola 的回应投了赞成票，因为这只是一个关于偏执的陈述，根本没有对我的问题提出答案。此外，甚至同一贡献者的评论也重申了这个问题。 WizzardOfOdds 支持这个观点（但你可能没有阅读所有评论来看到它）。 -jtsampson
编辑：2010-03-12 我很快就会发布我自己的答案，尽管 John Skeet 的答案是正确的 MD5 建议（注意 -g:none 关闭调试）。虽然它只涵盖了技术方面。 -jtsampson
2010-03-15 我在下面添加了我自己的答案。针对“安全”的含义，我的意思是Java代码的功能不会受到影响。对 Java 编译器的简单研究表明情况确实如此（有一些注意事项）。这些警告是“仅限空白”，并被几位海报指出。然而，这不是您想要向 BizOps 解释的事情。我的目标是引出“如何证明这样做的合理性”类型的答案，我得到了一些很好的回应。
有几个人提到了源代码控制以及随之而来的“乐趣”。我特别没有提及这一点，因为这种情况已经很好理解（在我的上下文中）。谨防“加油站”效应。请参阅下面我的回答。
How would one go about proving to management that a batch reformat of all .java files in a large code base (to place the code in compliance with the company's coding standards) is safe and will not affect functionality.
The answers would have to appease the non-technical and the technical alike.
Edit: 2010-03-12Clarification for the technical among you; reformat = white space-only changes - no "organizing imports" or "reordering of member variables, methods, etc."
Edit: 2010-03-12 Thank you for the numerous responses. I am a surprised that so many of the readers have voted up mrjoltcola's response since it is simply a statement about about being paranoid and in no way proposes an answer to my question. Moreover, there is even a comment by the same contributor reiterating the question. WizzardOfOdds seconded this viewpoint (but you may not have read all the comments to see it). -jtsampson
Edit: 2010-03-12 I will post my own answer soon, though John Skeet's answer was right on the money with the MD5 suggestion (note -g:none to turn debugging off). Though it only covered the technical aspects. -jtsampson
2010-03-15 I added my own answer below. In response to what does "safe" mean, I meant that the functionality of the Java code would not be affected. A simple study of the Java compiler shows this to be the case (with a few caveats). Thos caveats were "white space only" and were pointed out by several posters. However this is not something you want to try to explain to BizOps. My aim was to elicit "how to justify doing this" type of answers and I got several great responses.
Several people mentioned source control and the "fun" that goes along with it. I specifically did not mention that as that situation is already well understood (within my context). Beware of the "gas station" effect. See my answer below.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（24）
如果只是重新格式化，那么不应改变编译器输出。在重新格式化之前和之后对构建进行哈希（MD5 应该足够好） - 如果每个文件都是相同的，这显然意味着它不能改变行为。无需运行测试等 - 如果输出逐字节相同，则很难看出测试将如何开始失败。 （当然，运行测试只是为了展示它可能会有所帮助，但它们不会证明相同的二进制文件不会证明的任何事情。）
编辑：正如评论中所指出的，二进制文件包含行号。确保使用
-g:none进行编译以忽略调试信息。那么行号的改变应该没问题——但是如果你改变名称，那就是一个更严重的改变，而且确实可能是一个破坏性的改变。我假设您可以在没有任何人关心的情况下重新格式化和重建 - 只需将重新格式化的代码检查回源代码管理就应该引起任何关注。我不认为 Java 类文件中有任何提供构建日期等的内容。但是，如果您的“格式设置”更改了字段等的顺序，则可以> 有显着效果。
If it's just reformatting, then that shouldn't change the compiler output. Take a hash (MD5 should be good enough) of the build before and after the reformatting - if it's the same for every file, that clearly means it can't have altered behaviour. There's no need to run tests, etc. - if the output is byte for byte the same, it's hard to see how the tests would start failing. (Of course it might help to run the tests just for the show of it, but they're not going to prove anything that the identical binaries won't.)
EDIT: As pointed out in comments, the binaries contain line numbers. Make sure you compile with
-g:noneto omit debug information. That should then be okay with line numbering changes - but if you're changing names that's a more serious change, and one which could indeed be a breaking change.I'm assuming you can reformat and rebuild without anyone caring - only checking the reformatted code back into source control should give any case for concern. I don't think Java class files have anything in them which gives a build date, etc. However, if your "formatting" changes the order of fields etc., that can have a significant effect.
在商业环境中，您面临两个挑战。
从技术角度来看，重格式化器是一项成熟的技术。与散列/校验和相结合，只要语言对空格不敏感，从技术上讲，您就可以安全地执行此操作。您还需要确保在没有主要分叉等待合并的停机时间内执行此操作。真正的改变不可能与重新格式化分开，所以要分开进行。对于任何从事分叉工作的人来说，合并可能非常困难。最后，我只会在实现完整的测试用例覆盖之后才会这样做。因为原因2...
政治上，如果你不知道如何说服管理层，你怎么知道它是安全的？更具体地说，它对您来说安全吗？对于一个高级的、值得信赖的、控制着商店流程的开发人员来说，这是一项更容易的工作，但对于在一个大型的、政治的、繁文缛节的组织中工作的开发人员来说，你需要确保你涵盖了你所有的工作。基地。
我在 2010 年提出的论点也许有点太聪明了，但解析器、重新格式化器、漂亮的打印机都只是软件；它们只是软件而已。他们可能有由您的代码库触发的错误，特别是如果这是 C++。如果没有到处进行单元测试，并且代码库很大，您可能无法 100% 验证最终结果是否相同。
作为一名开发人员，我很偏执，这个想法让我感到不安，但只要你使用：
，那么你就可以了。
然而，请思考一下：管理层现在意识到您正在一个具有“大规模变更”的百万行项目中闲逛。重新格式化后，会报告以前未发现的错误。您现在是造成此错误的主要嫌疑人。是否“安全”有多重含义。这对您和您的工作来说可能不安全。
这听起来很老套，但几年前我记得发生过这样的事情。我们在夜间维护时段后的一天收到了一份错误报告，我只对 IIS 服务器。几天来，人们一直在说我一定搞砸了，或者部署了新代码。没有人直接这么说，但我从一位副总裁的眼神中看到了这么说。我们最终找到了一个错误，该错误已经存在于代码中，之前已推送，但直到 QA 人员最近更改了测试用例后才出现，但老实说，有些人甚至不记得那部分；他们只记得第二天遇到了一个新错误。
编辑：响应 jtsampson 的编辑。你的问题不是如何做，而是如何做。这是“如何让管理层相信它是安全的”。也许你应该问，“安全吗？如果安全，如何安全地进行。”我的陈述指出了你的问题的讽刺之处，因为你认为它是安全的，但不知道如何。我很欣赏重新格式化的技术方面，但我要指出的是，任何重要的事情都存在风险，除非你安排合适的人来处理它，否则它可能会变得混乱。这项任务是否会分散程序员的其他任务，让他们分心几天？它会与其他编码人员未提交的修订冲突吗？源代码是否正在修改？是否有任何对空格敏感的嵌入式脚本，例如 Python？任何事情都可能产生意想不到的副作用；对于我们的环境，很难获得一个没有人在分支上工作的时间窗口，并且大规模重新格式化将使它们的合并变得非常难看。因此，我不喜欢手动或自动进行大规模重新格式化。
In a business environment, you have two challenges.
From the technical perspective, reformatters are a mature technology. Combined with hashing/checksums, as long as the language isn't whitespace sensitive, you are technically safe to do this. You also want to make sure you do it during a downtime where no major forks are waiting to be merged. Real changes will be impossible to separate from reformatting, so do them separately. Merging may be very difficult for anyone working on a fork. Lastly, I would only do it after I've implemented complete test case coverage. Because of reason 2...
Politically, if you don't know how to convince management, how do you know it is safe? More specifically is it safe for you. For a senior, well-trusted developer, who is in control of the processes in a shop, it's an easier job, but for a developer working in a large, political, red-taped organization, you need to make sure you cover all your bases.
The argument I made in 2010 was a bit too clever perhaps, but parsers, reformatters, pretty printers are just software; they may have bugs triggered by your codebase, ESPECIALLY if this is C++. Without unit tests everywhere, with a large codebase, you may not be able to verify 100% that the end result is identical.
As a developer, I'm paranoid, and the idea makes me uneasy, but as long as you are using:
then you are OK.
However, ponder this: Management is now aware that you are mucking around in a million-line project with a "mass change". A previously undiscovered bug gets reported after your reformat. You are now chief suspect for causing this bug. Whether it is "safe" has multiple meanings. It might not be safe for you and your job.
This sounds trite, but a couple of years ago I remember something happen like this. We had a bug report come in a day after a nighttime maintenance window where I'd only done a reconfiguration and reboot of an IIS server. For several days, the story was that I must have screwed up, or deployed new code. Nobody said it directly, but I got the look from a VP that said so. We finally track it down to a bug that was already in the code, had been pushed previously, but did not show up until a QA person had changed a test case recently, but honestly, some people don't even remember that part; they just remember coming in the next day to a new bug.
EDIT: In response to jtsampson's edits. Your question wasn't about how to do it; it was "How to convince management that it is safe". Perhaps you should have asked, instead, "Is it safe? If so, how to do it, safely." My statement was pointing out the irony of your question, in that you assumed it was safe, without knowing how. I appreciate the technical side of reformatting, but I am pointing out that there is risk involved in anything non-trivial and unless you put the right person on it, it might get mucked up. Will this task detract from programmers' other tasks, sidetracking them for a couple of days? Will it conflict with some other coder's uncommitted revisions? Is the source under revision at all? Is there any embedded script that is whitespace sensitive, such as Python? Anything can have an unexpected side-effect; for our environment, it would be difficult to get a time window where there isn't someone working on a branch, and mass reformatting is going to make their merge pretty ugly. Hence my distaste for mass-reformatting, by hand or automated.
使用务实的方法：
Use a pragmatic approach:
我会用四个字。
源头控制。
单元测试。
I would use four words.
Source control.
Unit Tests.
嗯，这根本不安全，而且你不可能说服他们。作为一个管理过大量开发的人，我永远不会在任何收入所依赖的商业代码库中考虑它。我并不是说按照您喜欢的方式格式化代码没有优势，但是您的格式化不涉及某些代码更改的可能性为零。这意味着收益微乎其微，风险巨大。如果必须这样做，请在修复代码错误时逐步进行，不要一次性完成。对于程序员来说，这可能是一个很好的决定，但对于管理层来说，这将是一个糟糕的决定。
Well, it's not at all safe and you are unlikely ever to convince them. Speaking as someone who has managed a lot of development I would never consider it in any commercial codebase on which any revenue depended. I'm not saying there aren't advantages to code formatted how you like, but the chances that your formatting will not involve some code changes is nil. That means there's a huge risk for very little gain. If you have to do it, do it piecemeal as you bug fix the code, don't do it in a big hit. It may be a good decision for you as programmers but it would be a terrible decision for them as management.
我们在这里谈论什么管理？他们是否精通技术，能够理解什么是代码格式以及 Java 如何处理空格？因为如果他们不是，我认为他们没有资格做出这样的技术决定（即这样的问题应该委托给负责代码的人）。
但如果他们是，或者你试图说服你的“架构师”或类似的人，那么这就是信任第三方工具的问题。建议一个具有良好声誉的格式化程序，除此之外您无能为力，因为您没有编写格式化程序。
作为旁白，让我分享一个轶事。我们的架构师决定重新格式化所有文件。在数千个 Java 文件中，还没有发现任何错误（这已经是半年前的事了）。这让我相信 Eclipse 的 Java 源代码格式化程序。这种格式的好处是：
但它也有一些负面影响：
我个人认为负面大于正面。这听起来是个好主意，但实际上你收获并没有你想象的那么多。当您遇到一些格式非常糟糕的代码时，只需重新格式化该类或该方法，并将其视为朝着大目标迈出的一小步。
What management are we talking about here? Are they tech-savvy enough to understand the what code formatting is and how Java treats whitespace? Because if they are not, I don't think they are qualified to make such a technical decision (i.e., such questions should be delegated to someone who is responsible for the code).
But if they are or you are trying to convince your "architect" or someone similar, well, then it's about trusting a third party tool. Suggest a formatter that has a good reputation, other than that it's not much you can do, since you didn't code the formatter.
As a side track, let me share an anecdote. Our architect decided at a time to reformat all files. Out of thousands of Java files, not a single error has yet been found (and this was over half a year ago). This makes me trust Eclipse's formatter for Java source code. The benefits of this formatting were:
But it also had some negative sides:
I personally think the negative outweighs the positive. It sounds like a great idea, but in reality you don't gain as much as you think. When you come across some terribly formatted code, reformat just that class or just that method and see it as a small step toward the big goal.
重新格式化后您的单元测试是否通过？如果是这样，那么你已经把这个想法卖给了管理层！
如果您正在使用未经测试的代码，那么您将遇到更困难的情况。
Do your unit tests pass after reformatting? If so, then you've sold the idea to management!
If you're mucking around with untested code, then you'll have a much harder case to make.
您想要“代码符合公司的编码标准”[原文如此]并想说服管理层？
微不足道：安装CheckStyle，使其成为您流程的一部分，为其提供编码指南，并向他们展示整个代码库在 CheckStyle 上严重失败 。
You want the "code in compliance with the company's coding standards" [sic] and want to convince management?
Trivial: install CheckStyle, make it part of your process, feed it your coding guidelines, and show them that the whole codebase miserably FAILS on CheckStyle.
这是技术与业务不匹配的一个很好的例子。
技术人员希望这样做，因为它会使代码难以阅读，但是，除非代码非常糟糕，否则真正的原因是它冒犯了普通程序员通常微妙的情感和审美。
商界人士想要管理风险。如果有一些好处，并且这里没有商业利益，则可以承担风险，除非您认为使用重新格式化的源代码进行未来的开发会更便宜、更快和/或风险更小，总而言之诚实是很难推销的。
几乎根据定义，任何改变都伴随着风险。这里的风险很小，但也不是不存在（从管理层的角度来看），几乎没有好处。
还有另一个问题需要考虑：这种更改可能会对源代码控制造成严重破坏。跟踪谁更改了什么变得更加困难，因为对任何行的最新更改都将是重新格式化，因此您需要比较修订版本，这比简单的“责备”或“注释”命令更乏味。
另外，如果您有多个活动分支，则重新格式化代码将会对合并造成严重破坏。
This is a good example of the technical-business mismatch.
The technical people want to do it because it can make the code hard to read but, unless it's exceptionally bad, the real reason is that it offends the typically delicate sensibilities and aesthetics of the average programmer.
The business people want to manage risk. Risk can be undertaken if there is some benefit and there is no business benefit here unless you argue it'll be cheaper, faster and/or less risky to do future development with reformatted source code, which in all honesty is a tough sell.
Almost by definition any change has risk attached. The risk here is remote but isn't nonexistent either (from management's perspective) with almost no upside.
There is another issue to consider too: this kind of change can play havoc with source control. It becomes harder to track who changed what because the most recent change to any line will be the reformatting so you'll need to go comparing revisions, which is somewhat more tedious than a simple "blame" or "annotate" command.
Also, if you have several active branches a reformat of your code will cause havoc with your merges.
从某种意义上说，它是安全的，纯粹的格式更改不会对编译的内容产生任何影响，因此对代码在运行时的行为也没有影响。
值得记住的是，在以后处理源代码控制时，批量重新格式化代码可能会带来“乐趣” - 如果多个同事检查了代码，并且一名团队成员过来重新格式化它，那么所有这些副本都已过时。更糟糕的是，当他们更新工作副本时，将会出现各种冲突，因为这些格式更改将影响代码的很大一部分，而解决这一问题可能是一场噩梦。
It is safe in the sense that pure formatting changes will make no difference to what's compiled, and thus no difference to the behaviour of the code at runtime.
It is worth remembering that bulk reformatting of code can lead to "fun" when dealing with source control later - if multiple colleagues have the code checked out, and one team member comes along and reformats it, then all those copies are out of date. Worse, when they update their working copies, all manner of conflicts are going to appear, because those formatting changes will affect huge portions of the code, and resolving that can be a nightmare.
重新格式化代码与在 Word 中重新格式化文档相同；它改变了布局，从而改变了可读性，但没有改变内容。
如果所有文件的格式都相同，则代码将变得更具可读性，这使得维护变得更容易，从而更便宜。代码审查也可以更快、更有效。
此外，如果有良好的格式样式，则可以更容易地发现错误，因为它们无法隐藏；想想没有大括号的 if 语句和那些假想的大括号内的 2 个语句。
请务必聪明一点，在重新格式化之前签入代码并对其进行标记，这样您就可以返回到一个状态（并告诉人们这将是多么容易），重新格式化并签入并再次标记，而无需任何其他更改。
Reformatting code is the same as reformatting a document in Word; it changes the layout and thus the readability, but not the contents.
If all files are formatted the same the code becomes more readable, which makes maintenance a bit easier and thus cheaper. Also code reviews can be faster and more effective.
Further, given a good formatting style, bugs can be found more easily as they cannot hide; think of if statements without curly braces and 2 statements within those imaginary braces.
Do be smart and check the code in and tag it before reformatting, so you have a state to go back to (and tell people how easy that would be), reformat and check in and tag again, without any other changes.
回答管理层的这些问题，你就已经花了很长时间说服他们这是一个安全的改变吗？
这大约涵盖了它。
Answer these questions for management, and you will have gone a long way of convincing them it's a safe change?
That about covers it.
事实上，我可能会站在他们一边。当您打开设备进行修复或增强时，请重新格式化设备，并在重新投入生产之前对其进行彻底测试。它们第一次应该被正确格式化，但如果它们正在生产中，那么仅仅为了风格而重新格式化它们似乎是不必要和鲁莽的。
一致性是好的，但“愚蠢的一致性是心胸狭隘的怪物”。
Actually, I'd probably be on their side. Reformat units as you open them for fixes or enhancement when they will be thoroughly tested before going back into production. They should have been formatted correctly the first time but if they're in production it seems needless and reckless to reformat them only for style's sake.
Consistency is good, but "a foolish consistency is the hobgoblin of small minds".
我正在戴上我的经理帽子......
为了将其作为一个宏伟的项目来完成，无论争论如何，我都不会让你这样做。但是，我愿意对更改进行更长时间的估计，因为您正在修改现有文件以包含这些格式更改。不过，我要求您自行进行格式更改。
I'm donning my manager hat...
To do it as one grand project, I wouldn't let you do it no matter the argument. I would, however, be open to longer estimates on changes because you are modifying existing files to include these formatting changes. I would require you make the formatting changes its own check-in though.
感谢您的所有回复。
我说服管理层的最后论据；包括您所有回复的部分内容。感谢您的帮助。
技术：
重新格式化之前和之后：
(-g:none))
业务：
目的：遵守公司标准，该标准规定我们的源文件准确地表示代码的逻辑结构。
试点测试：
注意：在我的例子中，部分开发人员使用自动化工具“按照代码进行格式化”（如上面的一些答案所规定）进行了为期 6 个月的试点测试。虽然有些人认为重新格式化会导致更多合并冲突，但实际上并非如此。
这种看法是基于重新格式化的时间巧合。例如，考虑一个对汽车一无所知的人。有一天，他们的刹车失灵了。他们将原因归因于什么？当然是气体。这是他们放入汽车的最后一个东西（“加油站”效应？）。然而，显然，刹车和燃油系统是不同的系统，格式和代码更改也是如此。我们发现在我们的构建过程中不正确的签入是错误的。
最后，我希望有人能提供一个很好的链接，指向一项研究，显示与通用代码相关的生产力提高，因为很难向企业展示投资回报率。尽管就我而言，由于这是公司标准，所以我“遵守”。我只需证明“按代码格式化”与“批量格式化”相比更耗时
Thanks for all your responses.
My final argument to convince management; Bits of all your responses included. Thanks for the assistance.
Technical:
Both before and after a reformat:
(-g:none))
Business:
Purpose: to comply with company standards which prescribes that our source files accurately represent the logical structure of our code.
Pilot Test:
Note: In my case a pilot test was run over 6 months by a subset of the developers using an automated tool to "Format as you code" (as prescribed by some of the answers above). While some perceived that the reformatting caused more merge conflicts, this was actually not the case.
This perception was base on the temporal coincidence of the reformat. For instance, consider the person who know nothing about cars. One day their brakes fail. To what do they attribute the cause? The gas of course. It was the last thing they put into the car (the "gas station" effect?). Clearly however, brakes and a fuel system are disparate system as are formatting and code changes. We found that improper check-ins within the context of our build process were at fault.
Last I was hoping that someone would have provided a good link to a study showing productivity gains related to common code as it is difficult to show ROI to the business. Although in my case, since it was a company standard I had "compliance" on my side. I only had to show that it was more time consuming to "Format as you Code" vs. "Batch Format"
如果您使用 Eclipse 作为开发平台，您可以加载所有代码进入本地工作区。通过向管理层显示“问题”选项卡来向他们证明没有问题。
然后，右键单击并一一格式化每个项目 - 再次证明没有引入任何问题。
您可以在本地工作站上执行此操作，而不会对您的存储库造成任何损害。
老实说，如果您的管理人员缺乏技术性，以至于害怕格式化源代码，那么证明格式化后问题选项卡上没有出现问题就足以表明代码仍然没问题。
更不用说您可能会在源代码管理中标记旧版本，对吧？
If you are using Eclipse as your development platform, you can load all the code into the workspace locally. Demonstrate to management there are no problems by showing them the Problems tab.
Then, right click and Format each of the projects one by one - again demonstrating no problems are introduced.
You can do this on your local workstation without any harm at all to your repository.
Honestly if your management is so non-technical as to be afraid of formatting source code, then demonstrating that no problems appear on the problems tab after a format should be sufficient to show that the code is still fine.
Not to mention you will presumably have the old version tagged in source control right?
一种思想流派可能是不问就做，然后能够“看！”
当然，如果你把一切都搞砸了，你就会被解雇。您做出选择...
或者，源代码控制（或简单的备份），然后您可以随时将其回滚。
A school of thought could be to do it without asking and then be able to go "See!"
Of course if you wreck it all up then you'll get fired. You makes your choices...
Alternatively, source control (or simple backups) then you can always roll it back.
如果你的代码有足够接近 100% 的代码覆盖率，那么我认为风险可以降低一点。
然而，即使管理层同意代码库是安全的，我认为他们也会考虑必须证明支付员工花费数小时重新格式化代码的合理性，只是为了遵守（我认为）在开发过程中长期引入的标准生命周期。
If your code has near enough 100% code coverage then I think the risk can be lowered a little bit.
However even if the management agreed that the code base is safe, I think they'd have their eyes on having to justify paying an employee to spend hours reformatting code just to adhere to a standard that (I presume) was introduced long into the development lifecycle.
我目前的工作中使用 Jalopy。这是一个非常可靠的产品，它产生的输出非常简洁。这里最资深的开发人员在将代码库从 CVS 迁移到 SVN 时重新格式化了所有代码库，他必须执行一些测试以确保它从头到尾都能正常工作，现在我们有钩子来确保检查-代码格式正确。
话虽这么说，我认为你不能让任何人相信任何工具都是傻瓜（或错误）证明，因为没有这样的工具。如果您认为这样做的好处值得花时间和（非常小的）风险，请尝试让您的管理层相信您这样做的最大优势。对我来说，最大的优势将出现在以下情况：
因为如果您执行上述操作，如果您的代码已经格式化，那么当您比较 SCM 中的修订版时，您将看到程序逻辑的实际更改，而不仅仅是格式更改。
We use Jalopy here at my current job. It is a pretty solid product and it produces really neat output. The most senior developer here reformatted all the code base when he migrated it from CVS to SVN, and he had to perform some tests to make sure it would work all the way from start to end, and now we have hooks to ensure that checked-in code is properly formatted.
That being said, I don't think you can convince anyone that any tool is fool (or fault) proof, because there is no such tool. If you think the benefit is worth the time and the (very small) risk, try to convince your management the biggest advantage you see in doing this. For me, the largest advantage will come if:
Because if you do the above, if your code is already formatted, when you compare revisions in your SCM you will see actual changes in the logic of the program, and not just formatting changes.
如果单元测试的覆盖率很好，前后的测试结果就足够了。
If you have good coverage of unit test, test results before and after will be enough.
请注意一个具体事项：如果您的公司政策包括按字母顺序成员排序，请注意静态字段的顺序确实很重要。因此，如果您包含执行此操作的保存或清理规则，则可能会破坏您的代码。
Just one specific heads up: if your company policy includes alphabetic member sorting, be aware that the order of static fields does matter. So if you include an on-save or cleanup rule which does this, you might break your code.
从技术上讲，在编译的第一阶段，词法分析器会从源代码中删除所有注释和空格。这早在编译器识别任何代码语义之前就已经发生了。因此，任何空格或注释都不能改变程序逻辑中的任何内容。相反，如果添加几个空格或换行符会改变它的语义，那么该语言有什么用处以及谁愿意使用它？
在业务方面，您可能会为此使用一些专门的工具。我确信他们在网站上做广告说它们效果很好。
最后一点：如果你必须让你的管理层相信这一点，也许你应该寻找一种与更聪明的人合作的方法？
Technically, during the first phase of compilation, lexer strips all comments and the whitespace from the source. This is long before any semantics of code is being recognized by the compiler. Therefore any whitespace or comments cannot change anything in the program logic. On the contrary, of what use would the language be and who would like to use it if adding a couple of spaces or newlines would change it semantics?
On the business side, you are probably going to use some specialized tools for that. I am sure they advertise on their websites that they work great.
Final note: if you have to convince your management of that, maybe you should look to find a way to work with smarter people?
我会问管理层他们目前相信代码有效的基础是什么 - 然后证明相同的工具（测试、文档、小声音......）对于重新格式化的代码同样有效。我希望他们的答案是“测试”......
I would ask Management what is their current basis for believing the code works - then demonstrate that the same tool (tests, documentation, little voices...) works exactly as well for the reformatted code. I would want their answer to be "tests"...
我知道以前的答案都很好，但这里还有另一个可能的答案：Do a CRC重新格式化之前和之后的编译版本。由于编译会忽略空格、制表符、换行符等，因此编译后的版本应该与原始版本相同，这将向那些半技术经理证明一切都很好。
I know the previous answers are all fine, but here is another possible one: Do a CRC on the compiled version before and after a reformat. Since compiling would ignore the spaces, tabs, linefeeds, etc., then the compiled version should be identical to the original, and that would prove to those semi-technical managers that all is well.