re: Writing Clean Code VIEW POST

VIEW FULL DISCUSSION

Consistently formatted code is surely ideal. But previous efforts I've been a part of have suffered from some combination of the following:

  1. Lack of interest from all members of the team
  2. Differing opinions on what looks/reads best
  3. 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...

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).

code of conduct - report abuse