5 ms·
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.
by wheelerof4te 5y ago
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.
- junga 5y agoBut you are not me and here we are.
- lordpankake 5y agoOld-timers did without memory safety too, which is why I'm switching our company's stack over to good ol' C
- wheelerof4te 5y agoSome of the older programming languages had memory safety. C is not the only old programming language.
- tomjen3 5y agoDo you also wonder about the usefulness of git?
- wheelerof4te 5y agoSometimes, yes. But I never worked in a big professional team before, where git's features shine. And git != code formatter.
- scq 5y agoIn a team is also where code formatters shine, IMO. 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.
- unfocussed_mike 5y agoPreaching to the choir here I suspect, but if other lone developers are reading this: 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.
- ZephyrBlu 5y agoGit is insanely useful regardless of whether you're in a team or not. Having a history of your changes, being able to define an atomic change, branches, etc are all very useful even when working solo.
- tomjen3 5y agoI have never regretted issuing a git init command, but I have regretted not doing that. Granted when I am developing for myself, most/all commits are just going to master but even so.
- bombcar 5y agoGit is how we store all the white space changes as the formatting wars rage. Apparently some actual code changes are in there but we’ve never found them.
- maerch 5y agoSo many hours have been saved thanks to formatters. Not only writing it, but also countless hours in PR-reviews without senseless nitpicking. One of the best trends recently.
- judofyr 5y ago> Not only writing it, but also countless hours in PR-reviews without senseless nitpicking. 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.)
- deleted 5y ago[deleted]
- runarberg 5y agoIt’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 agoThey 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 agoMost 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 agoI 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.
- hhmc 5y agoWill you also forgo antibiotics the next time you have a raging infection, or do you only appeal to antiquity _sometimes_?
- wheelerof4te 5y agoKeep your straws, strawman. I don't want them, be they short or long.
- hhmc 5y agoIf you think this is a strawman, then you’re even more deluded than I thought. Best of luck, you’ll need it.
- sixstringtheory 5y agoJust because they did without them doesn’t mean they wouldn’t have preferred to have had them, given the opportunity. And I really doubt you’ve surveyed them all to make such an authoritative call on this.
- munificent 5y agoThere's two ways to look at how people of the past compare to people of today: 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.
- spc476 5y agoAgree. If I didn't want to have opinions, I'd join a cult.