So many formatters popping up. If the old-timers could do without them, I wonder about the usefulness of them.
The best code formatter is you.
The best code formatter is you.
One of the best trends recently.
I've never understood this point. Programmers will always find something they can nitpick about. Ultimately you want a culture which focuses on the critical parts: Correctness of code, good test coverage, big-picture architecture which has long-term impact. Bringing an auto-formatter into the picture may reduce some senseless nitpicking, but you haven't actually done anything to solve the real culture problem. If your team was getting blocked because people were arguing about formatting you have bigger problems that won't be magically solved by adding an auto-formatter.
To give some examples:
A while back I worked with one person on a project where we had both Prettier and super strict ESLint, and I would still get PRs rejected because they wanted the code to be slightly refactored in a way which was entirely subjective and had no impact of the correctness (e.g. "flip this negation") .
And right now I'm working on a team where we explicitly tag some PR comments with "nitpick". This will not block the PR from getting merged, but instead it's a way of saying "I prefer it this way, but it's not that important in the bigger scheme of things". This is also a signal that it's not something that we want to start a bigger discussion around.
(We use auto-formatters and linters as they are very useful.)
* 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.
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.
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.
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.
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.
1. They didn't have X, so obviously we don't need X now.
2. There were the ones who created X, so clearly they felt the absence of X was a problem to be solved.
I'm inclined to believe 2 comes into play more often than 1. The present was created by those living in the past.
But I never worked in a big professional team before, where git's features shine.
And git != code formatter.
The biggest advantages (to me at least) are that they almost entirely eliminate formatting from code review, and the consistent style makes it easy to read and edit code written by different people.
Git's features shine just as brightly, IMO, if you work for yourself.
Granted a good number of them are often not very relevant to a lone developer, but if you work for or by yourself on any projects over the long term, you should build git (or some other distributed source control, but probably git) into the way you work.
Not to excess, by any means. I use a very small subset of git's features and in practice many of my simpler projects don't even use branches, because it's not in the nature of the changes I am making to those projects or the time management I do.
But for example you should consider git an essential step between dev and live -- using it to deploy -- and you should look at how you could use it to facilitate staging and testing.
Combined with a changelog and relentless use of comments and notes, git helps "structured forgetting", which as a freelancer is pretty crucial; sometimes you work frantically on a thing for a month, get paid and then it comes back to you years later.
> And git != code formatter.
No, obviously, but the needs of the former are supported by the benefits of the latter.
That said, I use one for golang but not, in general, for PHP. I should find a code-formatter I can bend to my will for PHP, but after 17 years of increasingly complex lone PHP development, I know what I need from my own formatting requirements in order to manage projects.
Granted when I am developing for myself, most/all commits are just going to master but even so.
Apparently some actual code changes are in there but we’ve never found them.