Consistency is critical for reducing mental load when working as a team. Format your personal projects however you want, but when collaborating your editor should apply the standard format every time you save.
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.
> 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.
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.
Yes, 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.
> 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.
Well I'm quite proud of having owned a certain repo at work which takes exactly this approach. If I have to disable a rule more than once, I take a good look at whether we need it at all, so we have extremely few `eslint-disable` comments in the entire codebase. It's one of the cleanest and most transparent codebases I've worked in -- but that's also an artifact of me spending long stretches working in it alone and having little oversight of how I spend my time. So there's a tradeoff :)
Programmers don't love errors. In fact, we see time and time again that even just seeing the word "error" causes programmers to forget how to program. It's their kryptonite.
But they don't see value in warnings. Either you have a problem that needs to be fixed or you don't.
My point was that removing code (not just reformatting it) without changing behavior is a gain, not a loss. Art is the opposite.
That tells me that the code itself is not important; the task/instructions the code performs is the important part. Therefore code is a utility, not an artform.
Yes I want written instructions to be understandable to humans, so my code conforms to tool-enforced formatting standards 100% of the time, not subject to artistic interpretation.
This is one of the major differences between hobby programming and work programming. When you're writing code as a hobby, it can be anything you want: code can be art, instructions, math, beauty, a means to an end, an experiment... At work, code must ultimately be a tool that creates profit. It has to be manageable, consistent, and boring.
It is a mistaken idea that work programming is or must be boring. I think you might mean "boring" as opposed to unnecessarily "creative" or complicated. But not all work code is boring, boiler-plate code.
I think of "boring" in this context the same way my dentist calls me a nice, boring patient. He means no surprises for either of us, nothing out of the ordinary, just a mouth in good shape with maybe a cavity or two.
That's how I like to see code. I don't want to struggle to figure out what you're trying to do. I want to be able to read your code and understand it easily and get on with what I need to do.
The opposite of this, keeping the medical context, would be the orthopedic surgeon who was so excited about how badly my then 25-year-old wife had smashed her wrist. "I never see this much joint damage in someone so young. It's incredible." Not words you want to hear from a doctor!
>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.
Right, 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.
What 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.
Arguing 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.
> 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.
The 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.
Does 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.
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.
On 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.
I 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.
> 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.
> 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.
