5 ms·
Maybe I'm not articulating my point very well. I absolutely agree that consistency, in principle, is usually a very good thing. My objection is to the idea th
by ravenstine 2y ago
Maybe I'm not articulating my point very well.
I absolutely agree that consistency, in principle, is usually a very good thing.
My objection is to the idea that it's always a good thing, which it's not. Treating code formatting as rules rather than suggestions, in my experience, is a waste of time and unnecessarily tyrannical.
In terms of mere code formatting, I don't buy that there's a meaningful difference between 100% consistency and say 95%.
It's far more important that APIs and other conventions are consistent. When constructs in the code aren't consistent, it can be an absolute nightmare. When code isn't formatted well, it's usually just annoying and can be trivially fixed with automation.
- Aeolun 2y agoWhat I love, is a code formatting check on the server side. Just check that the code is properly formatted using Biome or Prettier. Everyone can set it up in their editor, or run it manually however they want, and nobody ever has to think about it. What I absolutely detest, is any kind of code formatting comment on a PR. If it cannot be enforced automatically, it’s not worth arguing about, and definitely not something to hold a PR up for.
- steve1977 2y ago> In terms of mere code formatting, I don't buy that there's a meaningful difference between 100% consistency and say 95%. I think you are contradicting yourself a bit with > Programming should actually allow for creativity, and where you decide to add spaces and newlines can actually add subtle but important communication as to the significance of a particular part of one's code. The point being that something small might have significance to one person but not the other. And that consistency is probably important, but there is a difference between consistency of your stuff and consistency between your stuff and stuff of others. So I think what it boils down to is that crafting hobbies are often more fulfilling not (only) because they have tangible outcomes, but because you can do them on your own and on your terms. If you were to do woodworking where you craft one piece of a bigger thing (say a part of some larger furniture), you would also have to produce very homogenic and precise output. And it probably would not be very fun and fulfilling.
- ravenstine 2y ago> The point being that something small might have significance to one person but not the other. Yeah, that's totally fair. I think conversations can be had with such cases, and I think that trying to effectively eliminate the conversation is a bad thing, which relates closely to my overall objection. Ironically, it ends up in conversation anyway unless a developer is always a good little goober and never marches out of sync. Maybe my mindset would be different if I saw great software around me, but I see mostly crappy and user-hostile software these days. I'm not sure whether strict formatting "standards" is of meaningful benefit for the users. > If you were to do woodworking where you craft one piece of a bigger thing (say a part of some larger furniture), you would also have to produce very homogenic and precise output. And it probably would not be very fun and fulfilling. Yeah, I guess you've identified where my thought in response to woodworking falls apart. haha If it were one's employment, it could indeed be as confining as being a programmer at BigCo.
- Arainach 2y agoArguing about what 5% is appropriate is a significant distraction. I do not believe that any benefits from allowing these discrepancies are superior to the reduced mental load in authoring, reading, and reviewing code of "the linter is automatic and true". If a rule can be written into a linter, simply have it automatically formatted and never argue about it again. It eliminates entire classes of argument.
- ravenstine 2y ago> Arguing about what 5% is appropriate is a significant distraction. Yes. > If a rule can be written into a linter, simply have it automatically formatted and never argue about it again. That is unless one believes to have good reason to violate that rule, in which case suddenly time is being spent having practically the same conversation in this part of the thread that I started.
- Arainach 2y agoThe point of automatic formatters is that they are universally enforced. There is no violation of the rule, even if you have a "good reason". If you have a pattern of good reasons, you can write to whoever controls your team's coding standards/linter rules and suggest a tweak, but you never have one-off violations, you just accept the automatic format.
- thunky 2y ago> My objection is to the idea that it's always a good thing If everyone doesn't follow the standards all the time then there are no standards. Code is not art, it's instructions. If you can't write instructions without adding your own avant garde whitespace brush strokes to it then yes coding for a professional company may not be your jam.
- digging 2y ago> Code is not art, it's instructions. I'll slightly disagree here because code needs to be read by a computer and by your human teammates. There are times when I'm frustrated because prettier is making a necessary but unintuitive choice and causing my code to become harder to read. But those are rare, and I would never trade them for the guarantee of readable code the other >99% of the time.
- ravenstine 2y agoYes, this is fundamentally where I disagree with the person you're responding to and what seems like most programmers (or perhaps mostly web developers). If code is just instructions, it would look barely comprehensible to [most] programmers. Again, maybe I came off as more extreme than I actually am, because I think that consistent formatting is a very good thing most of the time, but that last 5-10% that programmers in positions of power fetishize is where things can get frustrating and time can get wasted. The worst is when linter rules are used for things that should be evaluated by a human being in code review. At a previous workplace, someone thought it was a marvelous idea to try and enforce things like functions having no more than 6 lines or some other poppycock. My current workplace is OK, but even then there are some stupid rules like not being allowed to assign `this` to a constant, even though the function in-scope is being re-bound by some stupid middleware making it impossible to use fat arrows or `.bind` (in JavaScript). Sorry, but I'll assign whatever the f*** I want to a constant that isn't escaping the current scope in any way. What's also funny is that I've never worked anywhere that didn't have `eslint-disable` sprinkled everywhere. In many cases, these rules should be warning instead of errors, but because programmers love errors for some reason, virtually every rule violation needs to be an error.
- andoando 2y agoI think I agree. I've some seen anal linting rules that straight up make you refactor your code to make it fit. That I can't stand
- thfuran 2y ago>Treating code formatting as rules rather than suggestions, in my experience, is a waste of time How can it be a waste of time? The whole point is to avoid wasting time talking about formatting on PRs or seeing line noise on PRs because people have slightly different preferences or settings for code formatting.
- chihuahua 2y agoRight, exactly. Code formatting should be fully automatic (format on save, verify on commit) so that no one has to waste any time thinking or arguing about it, ever.
- cjonas 2y agoDoes your company not just use an automatic formatter? Set a prettier config, format the entire codebase and never have to deal with another formatting change in a PR ever again.
- ravenstine 2y agoThere's formatting, and there's linting. But my issue with formatting, while great most of the time, is that sometimes I want to violate it, and tooling around automatic formatting and format validation is usually installed with the intention that it is 100% correct all the time. Sorry, but as a senior programmer, sometimes it really should be up to me to decide whether code belongs on a single line, and I don't want to fight against automatic formatting or the CI pipeline throwing a hissy fit when I desire that discretion.
- Arainach 2y agoOn the contrary, as a senior developer you should be able to look at and see the team-wide benefits of consistency. You don't have to handhold new junior devs to learn the style, you don't need to watch their PRs to see if they're being consistent, and you don't need to argue with other senior devs about whether something should be on a single line or not. You just let the automatic formatter do its thing. Being a senior eng isn't about always knowing what's right, it's about knowing how to keep the team moving efficiently.
- hinkley 2y agoI think you’re selling you example short here. Linting and formatters should be about applying a minimal acceptable limit to code, not diluting everything to the same mediocrity. It’s been a long time since I ran into a formatter that I hate out of the box.
- dilyevsky 2y agoConsistency and standards irl are even more “tyrannical” not less bc you can’t change the thing easily after the fact