当您分叉一个项目并对其进行工作时,是否可以在实现功能/修复错误的同时贡献代码格式修复?
这方面的例子包括:
- 文件中的混合制表符/空格,您只需更改一行
- 跨文件的不同缩进
Pro 论点:修复格式将提高整体代码质量。
反对论点:修复文件不相关部分的格式将使工具指向您作为代码的作者,之后从事同一工作的人可能会产生错误的印象,即您编写了它。
当您分叉一个项目并对其进行工作时,是否可以在实现功能/修复错误的同时贡献代码格式修复?
这方面的例子包括:
Pro 论点:修复格式将提高整体代码质量。
反对论点:修复文件不相关部分的格式将使工具指向您作为代码的作者,之后从事同一工作的人可能会产生错误的印象,即您编写了它。
一个不错的比较工具可以设置为忽略空格,如果您已经完成了将大括号移动到新行之类的操作,这并不是说这会对您有所帮助。
如果我是你,我会提交两个更改:一个是实际错误修复,另一个是代码格式修复。
您应该记住,每个人的代码风格都略有不同,有些风格并不比其他风格更正确或更好。话虽如此,如果代码以非常糟糕的方式格式化,那么您应该修复它 - 正确格式化的代码可以帮助调试和代码审查。您将显示为更改的作者,但您不应该被误认为是模块本身的作者 - 任何半体面的源跟踪工具都应该显示谁在何时创作了什么。
我在这里提倡的是,可以而且应该忽略编码风格的微小变化——任何有足够经验的开发人员都应该能够阅读和理解代码。团队应该有一个整体统一的编码方法,比如变量名的驼峰式大小写、方法名的正确大小写、成员变量的下划线等,但是像 LINQ 语句的格式这样的事情可以留给个人开发人员(除非它是真的不可读)。在与来自不同文化和背景的成员一起从事开源项目时,您一定会产生差异。使用像 ReSharper 这样的工具可以帮助消除其中的一些差异,但在一个公共项目中,并不是每个人都会拥有 ReSharper(或者甚至是一个半体面的 IDE,具体取决于正在开发的内容)。
一定要纠正丑陋的东西的格式,但不要为小东西出汗。开发人员是工程师、艺术家和人类的结合体——你会有所不同。成为一名出色的开发人员的一部分是了解您可以接受什么以及必须改变什么。
成为一个成功的开发团队的基本规则是:“每个人都必须遵守一种风格,而且只有一种风格”。
不仅要修复格式,还要通知该代码的作者:如果每个人在编码风格方面都在同一页上,那么通过其他人编写的代码会事半功倍,并且让人们将其他人的代码保存为好。