在修改/添加到模块时重新格式化其他开发人员代码是否可以？

在团体氛围中开发并在某些代码库中添加或修改功能时。重新格式化以前的开发人员代码以使其达到当前的编码标准是否被认为具有冒犯性或不礼貌？我了解标准已经更改，并且可能会继续更改，但是如果有人通过并更改了代码格式，你们中的任何人都会生气吗？

明确地说，我不是在谈论更改任何逻辑，只是在混乱制表符和空格等。

编辑：我不仅为了代码标准而这样做，它还帮助我通读了他们的代码并更新了代码，因此在我开始修改关键应用程序之前，我可以完全理解已经实现的逻辑。

我认为只要达成标准就可以。但是请注意；请注意，其他文件是否有可能同时被修改。如果只是因为要更改格式而使它们的合并变得困难，那么它将不会很受欢迎。

是的，代码应属于项目。使代码符合标准将有助于减少项目的技术缺陷。如果您正在修改它，那么您目前对此负责。对于较旧的代码，原始开发人员可能不再在项目中或承担新职责。

进行这种更改时，最好在重新格式化后运行验证测试。如果它们通过了，请在进行功能更改之前检入代码。

编辑：在此问题的上下文中，重新格式化为标准是合适的。在没有标准的情况下，我建议提倡使用标准，而不是在格式存在标准之前重新格式化。重新格式化为个人品味/标准不应使用属于该项目的代码来完成。

我相信在修改/添加到特定文件时重构代码始终是一个好习惯。这包括更新代码的样式，以反映变量/方法和编码样式的正确命名约定。

我一直都这样做。旧代码应保持与新代码相同的标准，如果您在进行代码开发时未进行修正，则没人会这么做。我认为这在童子军规则下很重要。

我认为这是一种好的做法，并且是代码维护的必要部分。

我建议您在一次版本控制系统提交中检入格式更改，并在单独的提交中检入功能更改，以帮助您自己和其他人了解发生了什么。

我不会有任何问题，并且可能会感激……只要更改不是“宗教性的”。请不要遍历我所有的类，并将花括号移到该方法的第一行。如果格式是合法的“不同人的笔画”类型的东西，那么当有人走进来并在您最常编辑的代码上加上格式时，这会有些烦人。但是，如果您成为该特定模块的主要编辑器，则可以进行任何您认为合适的格式更改。

是。请“修复”您认为合适的代码。就像实用程序员在他们的书《实用程序员》中说的那样，没有破窗。如果代码不符合标准，我认为它是一个残破的窗口。

有多种存储库会在签入时自动进行重新格式化，以及一些小事情，例如根据平台获取源而在get上更改CR / LF配对。

进行自己的重新格式化有一个很大的缺点，就是大量的重新格式化会使您的增量检查变得混乱，并且如果存在回归问题，则更难找到有问题的代码块。

您可能会向您的领导建议，由于代码库很旧，因此应该一劳永逸地将其引入并重新格式化为当前标准，从而为各地的代码带来光明的新未来。

由于您是在谈论纯粹的“格式”问题（这意味着我们不是在修正错误，而是按照您自己的标准使其看起来很漂亮），所以我认为这取决于原始人员是否仍在维护代码。

如果创建者仍在进行该项目-这是不礼貌的。在您看来“看”对的东西不是对他们“看”对的东西，为格式化而修改代码并不客气。它还会浪费很多时间。

我曾经和一个非常有所有权的开发人员一起从事一个项目。多年以来，我已经开发出一种非常有条理的格式化我的代码的方式，我觉得这很容易阅读，不容易出现隐式错误，并且可以自我记录。另一方面，这个人更喜欢使用长行的所有隐式功能，这些行长300个字符，因此您必须拥有30英寸的显示器才能读取它，因为他认为行数比可读性更重要。他花了半天的时间翻阅我的代码将其更改为他的“首选标准” ...而我仍在并行开发中！第二天早晨，我来找两天的工作格式化为他的烂摊子，这很粗鲁，而且很浪费时间。

现在，如果开发人员不在了，而您又拥有“更好的风格”，那就去吧。

始终自动套用格式的代码，如果你的IDE可以做到这一点。

• 长期防止手动格式更改使您的版本历史混乱
• 格式化程序配置文件必须在所有开发人员之间达成共识（选择默认设置？-）
• 保存文件时使格式化代码和组织导入习惯成为习惯

例如，在eclipse中，您可以首先运行格式化程序并组织整个代码库的导入。然后记住在保存之前先按ctrl + alt + f。