Consistently formatted code is surely ideal. But previous efforts I've been a part of have suffered from some combination of the following:
Lack of interest from all members of the team
Differing opinions on what looks/reads best
Too much legacy code to visit
So I've basically landed here: to all who are driven to format new or legacy code, go nuts! People tend to fall in line if there's already momentum.
However: make any formatting-only changes In. Their. Own. Commit. If someone has to review a commit where the whole file changed to figure out why a bug was introduced, that will be a huge fail...
I build things with my hands. The human behind Shift - https://laravelshift.com, master of Git - https://gettinggit.com, and author of "BaseCode" - https://basecodefieldguide.com
If it's a new code base or new file, agreed. But what about modifying a legacy file to introduce/change actual functionality -- the automated formatter/linter may obscure the actual changes with a complete reformat, correct?
I build things with my hands. The human behind Shift - https://laravelshift.com, master of Git - https://gettinggit.com, and author of "BaseCode" - https://basecodefieldguide.com
To your point, do it in a separate commit. Run the formatter/linter one time manually across the entire codebase. This will provide a basis (momentum) and from then on only changed files need to be formatted/linted (which could be automated).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Consistently formatted code is surely ideal. But previous efforts I've been a part of have suffered from some combination of the following:
So I've basically landed here: to all who are driven to format new or legacy code, go nuts! People tend to fall in line if there's already momentum.
However: make any formatting-only changes In. Their. Own. Commit. If someone has to review a commit where the whole file changed to figure out why a bug was introduced, that will be a huge fail...
Agreed about momentum and separate commit.
However, most of your points are moot when automating this process with a formatter/linter as suggested.
If it's a new code base or new file, agreed. But what about modifying a legacy file to introduce/change actual functionality -- the automated formatter/linter may obscure the actual changes with a complete reformat, correct?
To your point, do it in a separate commit. Run the formatter/linter one time manually across the entire codebase. This will provide a basis (momentum) and from then on only changed files need to be formatted/linted (which could be automated).