When you fork a project and work on it, is it OK to contribute code formatting fixes along with implementing a feature / fixing a bug?
Examples of this include:
- Mixed tabs/spaces in a file that you need to change only a line
- Different indentation across a file
Pro argument: Fixing the formatting will improve the overall code quality.
Con argument: Fixing the formatting in an irrelevant part of the file will make tools point to you as the author of the code, and people who work on the same piece afterwards may get the wrong impression that you authored it.
A decent compare tool can be set to ignore whitespace, not that this will help you if you’ve done things like move braces to a new line.
If I was you I would submit two changes: one with the actual bug fix, and a second with the code formatting fixed.
You should keep in mind that everyone has a slightly different code style, and some styles are no more right or better than others. Having said that, if the code is formatted in a truly awful way then you should fix it – properly formatted code can help with debugging and code review. You will show as the author of the changes but you shouldn’t be mistaken for the author of the module itself – any half decent source tracking tool should show who authored what and when.
Edit:
What I’m advocating here is that small variations in coding style can and should be ignored – any sufficiently experienced developer should be able to read and understand the code. The team should have an overall unified coding approach like camel casing of variable names, correct casing of method names, underscores for member variables, etc., but things like the formatting of a LINQ statement could be left to the individual developer (unless it is truly unreadable). When working on open source projects with members from across different cultures and backgrounds you are bound to strike differences. Using tools like ReSharper can help eliminate some of these differences, but on a communal project not everybody will have ReSharper (or even a half decent IDE, depending on what’s being developed).
By all means correct the formatting of the ugly stuff, but don’t sweat the small stuff. Developers are a combination of engineer, artist and human being – you are going to get differences. Part of becoming an awesome developer is learning what you can live with and what must be changed.