Open question:

Do you and your dev team openly embrace using a formatter for your projects, or do you not? And why?

My senior dev is trying to argue that it creates too much noise for commits, especially on older files and it's driving me nuts because I religiously use it (default TS formatter in VSCode btw, nothing crazy or super opinionated!)

Well use a formatter right after we write tests. Which hasn't happened either.

Huh? Your editor just does it, CI verifies it’s still correct.

@Demolishun Just like that app major refractor, that is always months down the road, so don't worry about it for now, right? Lol

@asstrotrash What does "refactor" mean? lol

@petergriffin I see your predecessors (assuming it was them that is) were smart enough to turn formatting on save at the project level.

@jespersh same!

@asstrotrash well in my current company it’s more difficult, we have our own style rules and packages for that now. But in other companies we just made a editorconfig and prettier file with defaults and call it a day. After all, we didn’t care about the code style as long as it’s consistent.

If it's an old file, format it first and commit that.

Then make your changes, easier to follow the diff that way and not loose the actual changes in the same commit.

@C0D4 good for commits, but the problem that the pull request has noise didn't change.

Maybe it's best to run the formatter for the whole project when you take it into use, and take those in as a massive PR.

Noise is supposed to be there if it wasn’t formatted before, really don’t see a reason to complain about it… the alternative is wasting time in PRs cause “fix spacing” or “uppercase/lowercase”.

As long as the team uses the same formatter with the same rules, the noise will be transitory.

@electrineer I like the massive PR idea. If bitbucket can show zero diff after disabing the "show whitespaces" in the PR, it is a total win

I can’t code without “format on save” any more. I’m a slave to the tooling.

The main concern with formatters is: do they have sufficient options.

One example is Prettier.

Prettier will by adhere to a certain max row length.
In some scenarios I’m not ok with that.

For example in css selectors with commas, it’s confusing to add newlines.

(Some of you might say ”why on earth would you even have a 80 char long selector” - the answer is 3rd party component style overrides where you are forced to adhere to their insane structure)

Another example is implicit rules:
If I create an object with 2-3 props I like a oneliner.
If I use more than that I like one line per prop.
Prettier will sometimes change all of that.

The senior’s argument is somewhat nonsensical: if you enforce a autoformatter once that saves time in future PR reviews spent correcting formatting mistakes.

However he does bring up a valid concern: you don’t want a ton of future PR:s to change formatting in all touched files.

Might be better to do a big ”format all files” PR.

But the downside is of course: then many git blames will point to that PR and you’ll have to put ina bit of extra effort to find previous changes before it