3 ms·

It’s not that formatters are essential but they are extremely convenient. They don’t just save you from formatting your own code, they also: * Prevent argument

It’s not that formatters are essential but they are extremely convenient. They don’t just save you from formatting your own code, they also: * Prevent arguments on which formatting convention to adopt, * Save a peer reviewer from shallow comments if formatting conventions are broken, * Prevent fill-in white space commit from filling in the git history, and * Decrease the risk of senior developers imposing weird styles on the code base. Formatters might help you write better code by freeing you from worrying about one aspect of coding, but—much more importantly—they help create and maintain a better culture around your code.

majkinetor 5y ago
They also: 1. Make programming more boring 2. Prevents me organizing related thoughts on single lines 3. Prevents me doing meaningful and more readable indentation in specific contexts (such as align on equal sign etc.) I don't like them, nor I like any of the style checkers. The equivalent is aS if somebody wrote a book, and you give it to GPT-3 to make it more readable for entire world. Fascinating BS.
- hhmc 5y ago
  Most code formatters have pragmas to allow you to break out of the autoformatter, for when you really do need to override (your case 3).
- cinntaile 5y ago
  I can see why it is preferred for teams, if you don't work in teams you can decide for yourself of course.
- sixstringtheory 5y ago
  > Make programming more boring This is a terrible argument for anything to do with programming/code. It is pure opinion and preference and therefore is not falsifiable. If you’re on a team of one, go wild. But if you’re on an actual team trying to get things done, please don’t bore the other people to death with the “interminably soul crushing debates over code formatting” as the article aptly puts it. The team wants to see exciting results, not “exciting” code. Code is a means, not an end. And especially if you’re on the job, you are not being compensated with excitement, but money. Go seek excitement in your personal time. Formatters are not comparable to GPT because the code semantics have not changed, only the form. You just don’t want to retrain yourself to read code that isn’t written exactly to your liking. That’s laziness.
Hendrikto 5y ago
Formatting is NOT the purely stylistic choice many code formatter authors make it out to be, though. It can greatly affect readability, lead to/prevent unnecessary merge conflicts, and aid in/stand in the way of using nice VCS features (blame, revert, bisect, cherry-pick, …). Many automatic code formatters ignore and do not optimize for these metrics.
- sixstringtheory 5y ago
  I’ve never seen a formatter cause merge or blame issues, but that could be because I always have them run on a precommit hook and even then always squash all commits on a PR so there is never a commit in mainline history solely for code format. I would not admit a PR solely for formatting, either. Git history trumps code style IMO, I would not e.g. add a formatter to a legacy codebase and then reformat everything, or do so after changing a rule. Only diffs get formatted.

majkinetor 5y ago

They also: 1. Make programming more boring 2. Prevents me organizing related thoughts on single lines 3. Prevents me doing meaningful and more readable indentation in specific contexts (such as align on equal sign etc.) I don't like them, nor I like any of the style checkers. The equivalent is aS if somebody wrote a book, and you give it to GPT-3 to make it more readable for entire world. Fascinating BS.

hhmc 5y ago
Most code formatters have pragmas to allow you to break out of the autoformatter, for when you really do need to override (your case 3).
cinntaile 5y ago
I can see why it is preferred for teams, if you don't work in teams you can decide for yourself of course.
sixstringtheory 5y ago
> Make programming more boring This is a terrible argument for anything to do with programming/code. It is pure opinion and preference and therefore is not falsifiable. If you’re on a team of one, go wild. But if you’re on an actual team trying to get things done, please don’t bore the other people to death with the “interminably soul crushing debates over code formatting” as the article aptly puts it. The team wants to see exciting results, not “exciting” code. Code is a means, not an end. And especially if you’re on the job, you are not being compensated with excitement, but money. Go seek excitement in your personal time. Formatters are not comparable to GPT because the code semantics have not changed, only the form. You just don’t want to retrain yourself to read code that isn’t written exactly to your liking. That’s laziness.

Hendrikto 5y ago

Formatting is NOT the purely stylistic choice many code formatter authors make it out to be, though. It can greatly affect readability, lead to/prevent unnecessary merge conflicts, and aid in/stand in the way of using nice VCS features (blame, revert, bisect, cherry-pick, …). Many automatic code formatters ignore and do not optimize for these metrics.

sixstringtheory 5y ago
I’ve never seen a formatter cause merge or blame issues, but that could be because I always have them run on a precommit hook and even then always squash all commits on a PR so there is never a commit in mainline history solely for code format. I would not admit a PR solely for formatting, either. Git history trumps code style IMO, I would not e.g. add a formatter to a legacy codebase and then reformat everything, or do so after changing a rule. Only diffs get formatted.