Hacker News Reader

Comment by ravenstine | Hacker News Reader

At a level or two down from the abstraction of company size, crafting hobbies are also a reprieve from the tyranny of linters. So many programmers today believe that code is always better when it all looks identical. Consistency is a good thing, but not when it's expected to be absolute. 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. Most places I've worked in the last 6 or so years are obsessed with tooling and add so many lint rules that it's often impossible to merge your pull request if you decide to format your code in a way that violates the rules in some trivial way.

With woodworking, you can just do the thing. OK, I don't do woodworking myself, but both of my parents do, and I know that they don't spend their time bikeshedding or homogenizing their work. The tools they use are intended to help them accomplish something and aren't there to prevent you from doing anything.

It's possible to do personal software projects however one wants, but one will no doubt be faced with the modern compulsion to want to "do the right thing" and add a bunch of time wasting tooling. If you don't, and you share your code, inevitably someone is going to want to add a bunch of rules and bureaucracy to your software that was already working and free of serious problems in the first place.

View on HN

How you choose to add whitespace to your code is not a meaningful outlet for creativity. Linters are a great tool for eliminating bike shedding.

I don't think wood working per se gives you more flexibility than building software. It's wood working as an individual, not part of a team, so you can make your own decisions and not answer to anyone. If you were a one man software consultant you would have the same amount of autonomy.

It’s devex. Not for you, but for the reader. It’s part of the craft. We can argue about whether craftsmanship is creative or skill, but at the end of the day it’s satisfaction that they are chasing. Satisfaction they are denied at work.

Not that they can’t find at work. It’s actively taken away from them.

As a one man software consultant, I just want to point out that you are working with clients, in their systems, on their problems. You provide advice, they make the decisions they deem best for their company.

You get to choose the problem spaces and teams, which is a degree of autonomy. But it is not quite so free as “making your own decisions and not answering to anybody.”

If you want to sell your woodwork you would have similar issues.

> How you choose to add whitespace to your code is not a meaningful outlet for creativity.

I'd like to mildly disagree. Using whitespace to group functionality together in "paragraphs" and aligning the horizontal indentation in the clearest possible way is not too far away from editing a short story to make it flow better.

Earlier today my linter rearranged multiple "key: value" one-liners into two-liners and the end result is both objectively and subjectively worse.

Yeah, it's proto-editing, but with such limited degrees of freedom in the activity your creative options are pretty limited and as time goes on and on the endeavor starts to look like this: https://xkcd.com/915/

Interesting, I can't tell if the comic is about "people will become obsess and develop taste in what they see every day", or "people will develop preferences to separate themselves into groups".

I normally just auto-apply `black` to my code, but occasionally I feel the need to have things arranged in a way that is easier to read -- e.g. a list of several dictionaries. In that case, I just put a comment telling it to stop reformatting at the start of the block, and another at the end.

Aside from edge cases, Black is life. Saves brain cells for the important stuff.

This is why I like when formatters give you some wiggle room in how the rules are applied.

Like, in Prettier, adding a trailing comma to a short list of items will tell the formatter to put each item on it own line, while removing the trailing comma will keep each item in a single line (if the line length is not too long).

> objectively

I do not think that word means what you think it means

Yep. Imagine being a woodworker on a massive project like a large sailing vessel or Japanese castle. Suddenly coordination and collaboration requirements go right back up. Now you can't just wing your project. You've got to make sure the part your building matches the agreed upon spec and hope the teams you're "integrating" with have also followed the spec. When one of those teams gets "creative" suddenly things aren't fitting together and progress on the ship crawls to a halt.

When I think of going multiplayer with my hobby and doing something big, I'm not thinking about what you described - that's just walking into bullshit and letting everything interesting about your work be suffocated. No, I'm thinking Skunkworks, or Xerox PARC. I imagine others are too.

This happens literally every single day in residential construction. Aside from the building code, there isn't typically a "spec" for construction. The plan doesn't specify "this wall shall be plumb to within +/- 0.001 radians". Somehow, cabinets still get hung even though the framer framed a crooked wall on top of a crooked stem wall all because foundation guy was hungover that day.

That’s because average residential construction has some tolerance for error (and is therefore poor quality imo).

Sure - perhaps not plumb to within +/- 0.001 radians, but there’s still an expectation that the wall needs to be vertical within some error tolerance band (even if not specified). Error correction happens real-time - the cabinet guy compensates for the wall error, and so on.

That’s also why I find residential construction so shoddy (the US at least) - electrical junction boxes are always a little off-angle, cover plates aren’t flush, etc.

The entire field of ASCII art indicates that your first sentence is dead wrong.

I curse the inferior linter formatting and at the same time would not have it any other way because why? Some diva would come in and put up a MR reformatting half the code base to their preferred way, mixed in with the actual change they are making and I would have to hunt for the actual changes in the reformatting noise. And then we would spend half a day arguing about it like in the good old days. Fast forward six months and there would be 6 different code styles in the codebase and it would just be terrible.

:deep breaths:

Sorry. Guilty party here. I used to be that diva at times, but also came around to your point of view after being on the other side of that several times myself.

But I think the biggest thing as I move up and spend more time reviewing code than writing it...style preferences make it so much easier to review code. Linters have given back years of my life at this point!

Why not just set up a rule to auto-format the code before it is committed so that nobody wastes time discussing formatting trivialities and the repo stays consistent?

It would be fantastic if there was a good normal-form formatter I could use for local work, and let automation format the code back to lint style. Unfortunately with something like IntelliJ/Java the commit-time reformat is not reversible. Maybe google's Java formatter is, hmm.

In JavaScript land, prettier auto-formatting the code on file save is quite lovely.

I would not be a fan of commit hook auto-formatting.

In my experience, it is not the divas who are the problem, but inexperienced developers (especially ones from non-CS background) who have a weird/no sense of formatting. I have seen my share of strange, inconsistent formatting in code reviews with junior developers.

I've worked in a place where reviews were obsessed with coding style. No one noticed serious bugs, but forget a space in the right place and you'd be doomed. And yet people still managed to rewrite stuff to their preferred style while managing to not violate any rule. No prescription about function and variable names? they'd change every single one their way. No prescription about argument alignment, they'd change it. Everything not esplicitly forbidden was an outlet to express their creativity or maybe tame their frustration.

This has never been a problem for me. Coding guidelines, clang-format and precommit scripts can do this automatically. Also a senior should reject or revert the work of the diva. You shouldn't accept this at all.

> Some diva would come in and put up a MR reformatting half the code base to their preferred way, mixed in with the actual change they are making

Nice. It adds a bit of spice to your git-bisect bug-hunting, to keep you on your toes.. Who doesn't like a good challenge?

I think you’re romanticising woodworking a bit here. A large saw is specifically built to allow doing a single, precise cut, in exactly the same way, over and over again. The tools are absolutely made to prevent you from messing up the various ways, it’s just that you don’t use the professionals tools at home.

And indeed that’s something I’d apply to software: both hobbyists and small companies are tempted to use professional tools (as in, intended for lots of engineers collaborating) for small projects or a low number of collaborators that don’t warrant such stringent rules.

> A large saw is specifically built to allow doing a single, precise cut, in exactly the same way, over and over again.

Ignoring hand tools, which give you precise, tactile control ... I'd still argue with this.

There are tools for specific things and they're meant to reduce error. But a router (woodworking) can be used to do half the stuff you want/need to do. A table saw can make straight cuts, rabbets, joinery.

The tools themselves (outside of specialty ones) are generally multi-purpose and allow for experimentation and creativity.

Programming tools are no different. All tools are like this.

OP's complaint is about syntactical differences and that's just because his team doesn't agree with him.

And tbh, to me, the fun creative part in programming lies in architecture, not how I space my code. With woodworking, the creative part is how I put it all together but not the actual cutting part.

Highly compensated people doing manual labor for fun are romanticizing woodworking. Full stop.

Trying to de-romanticize it means you have absolutely no idea what motivates most of us.

Signed, someone with restored antique Stanley wood planes, Japanese saws and who drools over Lee Valley product reviews.

Most of the stuff in the lee valley catalog is the same garbage you can get at rockler or any other tool outlet. The only thing possibly drool worthy are the Veritas tools. For the longest time I felt the same as you, I had assumed everything from LV was the same quality or at least close to the Veritas line. The truth is most of the LV stuff is garbage. On the other hand everything from Lie Nielsen is phenomenal, it's just not always in stock.

I spent a lot of time searching for and restoring old tools. I finally realized I was spending way more time on the tools than actually using them.

That’s not the arrangement of the words “Rockler” and “garbage” that will get you upvotes in r/woodworking.

If you had a Woodcraft in town you’d only go to Rockler for things you can’t find at Woodcraft. Which is largely cabinet-making and air handling equipment.

Lee valley and veritas are mostly making reproductions of golden age Stanley tools before the race to the bottom (what the kids call enshittification) started, with a few omissions or improvements. They aren’t garbage, they’re low volume. That makes them less appropriate for people being paid by the hour or piece.

I live equidistant, 15 minutes, from a Rockler and two Woodcrafts and I am not concerned about what would get upvotes in /r/woodworking.

I went to rockler this morning to get a reamer because the only reamers at Woodcraft are for pen making. With the exception of big brands like festool or powermatic most of the tools they sell at rockler are not great tools. This reamer is not great.

That’s kind of missing the point here (I actually do enjoy woodworking as a hobby! :)

OP complained about all the strict rules software engineers have to abide by, while woodworkers get to have all the fun with sharp tools, nobody telling them how to use them, and generally freedom at how they do stuff. But that’s precisely the perspective of a highly compensated person doing manual labor for fun, not the one of a professional woodworker. It’s like someone cooking fancy once or twice per week saying chefs have such a great job because they get to dice the onion the way they like. Ask any professional chef how well that works.

Something you do as a hobby will always seem more fulfilling, because it’s a hobby. Anyone doing it professionally very likely also has strict rules to follow, you just don’t know about them - because you’re not a pro.

Note really. A table saw is incredibly versatile tool. Yes, it has a bog standard purpose of ripping stock to width, but there are scores of uses beyond that. E.g., removing the fence and freehanding a 20 foot piece of baseboard through it to cut a scribe. There are plenty of professionals who do that. Source: I used to be one.

> 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.

Isn't this part of the problem? If the purpose of code is to be understandable, the important communications shouldn't also be subtle. Your intention that the extra empty line before a block of code signals "This is the important part" is likely to be entirely lost on a reader of the code (especially in a codebase where the formatting isn't consistent so those spare lines are littered everywhere). Much better to leave a comment saying "there's a subtle but important thing going on here".

> Much better to leave a comment saying "there's a subtle but important thing going on here".

Sure, but don't let perfect be the enemy of the good. Well-meaning engineers frequently don't document their code at all. It's why I advocate programmers at least use descriptive variable names and function names; what I call "self-documenting code".

It still falls short of well-documented code but, as I say, gets you "good".

For sure, well-written code often doesn't need comments to explain itself; my point was that "there's an extra space here so you know this bit is important" is pretty much the opposite of that.

I do use whitespace (empty lines) to "group" parts of a function the way paragraphs group thoughts in prose. For a function it might be as simple as param-check, setup, loop, tear-down. But it makes it a little clearer that some lines of tightly-grouped code represent an "activity" (sub-activity?).

As an example, your own comment three above is split into three parts (quote and two sections of your own). Plus my comment here, split into two.

Code has its own flow and natural groupings just like human language, and adding spacing to match makes it easier to understand even though it is subtle.

> the tyranny of linters

This is a take I don't think I've seen before. Is someone actually mad prettier is changing their single quotes to double quotes? Are they mad some line is breaking at some word?

Certainly I've never been. I use linters / formatters even when I'm working solo because the mere concept of having to think where to break lines is meaningless disruption from the actual goals I have.

If you _really_ want to break a line somewhere, just add a comment in between and your linter will comply.

> Is someone actually mad prettier is changing their single quotes to double quotes? Are they mad some line is breaking at some word?

Yes, both of these.

Obviously there are huge benefits to auto-formatting in large teams and popular open source projects, but some people also find benefit in having control of alignment, line breaks, indentation etc.

for some people talking about whether it's best to put a curly brace on its own line or on the same line as an if condition is like talking about which religion is the one true path to paradise...

Strict adherence to formatting rules can impair readability, yes.

Before back-tick strings in JS, it was useful to employ both single/double quotes for strings -- you'd use one most of the time, and then if you needed to embed a bunch of that quotation mark in a string literal, you'd switch to the other one.

    'my string'
    'my other string'
    "insert values ('foo', 'bar', 'baaz')"

A formatter with naive "single quotes only" rule would obliterate the last one to:

    'insert values (\'foo\', \'bar\', \'baz\')'

unless you remember, before you hit save, to add a directive like:

    // linter pwease preserve my qwotes

I still use linters and formatters every day, and on balance I think they're good to have, but it's ridiculous to pretend they don't have downsides, or that there isn't room for the occasional dash of human intervention in the automation; hence, the linters which have // linter pwease directives.

The key point here is that the formatter has to be sufficiently advanced to know to do the right thing the vast majority of the time. Once it gets there, and once you've gotten used to the code it produces, it's better. Note that the "prettier" formatter will do the right thing in JS here, at least with the default config. It will even switch "\"string\"" to '"string"' for you.

Linting is a bit of a different beast, because linting includes changes to the code behavior itself, not just syntax. In JS there are so many footguns, that linting can often be pretty involved/strict. I think most of the people who don't like linting in JS either aren't aware of the footguns, or don't do very much code review and haven't worried themselves much with "what sort of bizare and unusual ways can this fail" sort of a thing.

If you use linters without auto formatters you are choosing tedium.

Seriously. Python Black is a godsend. I don't have to waste brain cells on formatting minutiae, just right-click and go "format my code, please." It's consistent, it works, and IDGAF about the details.

The only formatting that drives me up the wall is people using K&R braces in C# or Java. It's not 1970 anymore, and we're not all typing on green-screen terminals. It's like people fetishizing vim or emacs over modern IDEs.

..huh? But either way, should you ever be annoyed by K&R again next time you work with C#, you can trivially change it by setting csharp_new_line_before_open_brace = none in .editorconfig and running dotnet-format tool against solution files.

K&R doesn't just mean the opening brace isn't on its own line, it also means single-line blocks have no braces at all. Always using braces but not putting the opening one on its own line is 1TBS (not the best name, but I don't know what else it's called).

You can omit them too (at the risk of legibility in some conditions).

All these are configurable (and not enforced by default but you can definitely do so with .editorconfig).

It is also fairly popular in C# to use expression-bodied members where they have just a single expression/statement e.g.

    class Test {
        public int Property => 42;
        public void Method() => Console.WriteLine(42);
    }

Yeah, I think OP's point is that nobody should be omitting braces in this day and age. Maybe there's a setting to force the use of braces too.

You know what annoyed me as a C/C++ programmer? People using Microsoft style braces... But OK, if you are using Microsoft-Java, then Microsoft rules apply.

AFAIK there is no rule in K&R requiring no braces for single-line blocks. In that situation, braces are optional.

The K&R style was hugely influential on Java and many other languages, it has nothing to do with green-screen terminals (I used those, as well as white and amber), it is just a style. I also moved on from vi, and use IntelliJ and Sublime most of the time.

The only difference between K&R braces and Java braces is that they combine lines on if-else. The Java guys did it because it enabled them to fit more code on to overhead slides. Overhead slide projectors predate green-screen terminals BTW...

You dont like kitchens where every cabinet is different slightly different size/color/material?

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.

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.

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.

> 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.

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.

> 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.

> 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.

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.

> I'll slightly disagree here because code needs to be read by a computer and by your human teammates.

I still don't think that makes it art and this is why: art can't be simplified. Code can.

Take that to it's extreme and you see that code can be simplified down to nothing without anything being destroyed. Art can't.

Maybe you could say that the act of programming (or simplifying) is an artform, but that's not what we're talking about here.

We're talking about the product of that process, which is just instructions to accomplish a task.

> Take that to it's extreme and you see that code can be simplified down to nothing without anything being destroyed.

I disagree. The thing being destroyed is readability and common understanding with your fellow programmers.

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.

> Code is not art, it's instructions.

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!

This is binary thinking and loses important nuance.

I 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

>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.

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.

There'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.

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.

Consistency and standards irl are even more “tyrannical” not less bc you can’t change the thing easily after the fact

I'm just happy to have gone six years without wasting half a day a month debating about formatting or whims.

> Most places I've worked in the last 6 or so years are obsessed with tooling and add so many lint rules that it's often impossible to merge your pull request if you decide to format your code in a way that violates the rules in some trivial way.

Shouldn't all the lines of code uploaded in a pull request be automatically formatted into the coding style preferred by the reviewer anyway? It should be like an automatic translation done by some bot or something.

That desire is in conflict with a desire for the reviewer to see only the changes and many of the diff tools don’t diff this reformatted code against that reformatted code but rather work on the pre-reformatted.

It could obviously be done, but involves a yak shave that isn’t clear that it brings enough value to be worthwhile.

That's my main concern, I want to review the changes, not formatting opinions.

I do not get it.

If it is formatted to the formatting rules before every commit, how can there ever be formatting opinions?

What am I missing?

What bot? You create a branch, you push button in github UI, merge request is created. There's no bot.

It's not a bot but formatters like prettier for example make it very easy to set them up as git-hooks, where the formatter is applied on commit. Meaning, unless you specifically commit without hooks, all committed code should comply with the formatter.

For linting (e.g. eslint in the JS-space), this is also possible, however, most linting-processes tend to run just long enough to be annoying when run on every commit. In the monorepo I work on we created a command "prep-pr" which specifically addresses this issue - run it before creating a PR, and the CI-pipeline will mostly be green, at least in terms of linting/unit-testing.

We can't check in anything that fails the linter, but we can also automatically format the code very easily.

> tyranny of linters

Thank you for that: "linters" (but as a person's role, not as a tool).

Pretty sure that contributed to my early retirement from the industry. It didn't used to be that way — perhaps because there were fewer cooks; perhaps because of a more cavalier, cowboy-style approach to coding.

I definitely preferred the days of the open range....

If there's a small team, individual freedom can be perfectly fine, as everybody knows everyone and it's easy to talk with each other in case there are discrepancies.

For larger projects however, not having tooling set up that enforces certain consistency is an absolute showstopper for me. I'll either introduce it or I'll quit; I simply do not want to waste my time with developers squabbling over arbitrary formatting-choices or irrelevant coding-style-details that can easily be enforced by some tooling.

Of course, developer-experience is paramount. Meaning, the tooling must be easy-to-use and generally not stand in the way. Otherwise it can indeed create a lot of friction which will annoy everybody. But once this has been set up (properly!), it will make a lot of silly discussions and choices obsolete.

I hear you. But I’ve been programming for 30 years and I have some strong intuitions around where my code needs an empty line to space things out. Stuff like that. The day I first tried gofmt and it removed some of my carefully considered whitespace, I turned around, put blood on my hands in the old way and made a promise to the night that my soul belongs to me and gofmt will never sully my code with its corporate BS aesthetic.

Some consistency in a codebase is good. Naming consistency. Indentation. But people go too way far with it. Who cares if your JavaScript makes consistent use of semicolons? It doesn’t matter. It just doesn’t matter.

This is why linters are configurable; if your team doesn't care about consistent use of semicolons, ignore that linter.

Right?

Sure; but when I join a team and they've already got a linter set up with stupid pedantic rules, they never seem to appreciate my complaints about it. "Oh god, can we not have that conversation again!". I understand. But nobody is happy.

Carpentry isn't my jam, but I've taken up piano. I love it.

I have similar feelings as GP about Black (probably the most popular python code formatter), which goes by the philosophy that linters should not be configurable because that just moves conversations about styles from the code to which rules to use.

Black also behaves decently wrt empty lines. It does have some opinions on that, like two lines between functions and in some other contexts, and at most one line elsewhere. But inside function bodies, it will collapse multiple consequent blank lines into a single one, but it will never remove them altogether, so it's still possible to use them to logically structure code.

> a reprieve from the tyranny of linters

Consistency is dramatically overrated. We all read through comment threads on HN where each is written in it's own style and nobody has a problem understanding it. I read through open source repos all the time, which all have their own styles and which are often not self-consistent; my comprehension is not impaired. I have worked with teams that enforce linting with a religious fervor and teams where anything goes. The anything goes team is probably more productive and with a comparable rate of bugs (but I don't have the metrics to prove it). Personally, I don't feel like my comprehension is better or worse in one setting or the other.

The difference I do notice is that when there are no linters, nobody wastes time trying to figure out how to work around it for a few lines. A great example is Eigen matrix initialization through the stream operator overload [1]. You really want to manually format that so each row is on it's own line. If you use clang-format in such code, it will be littered with

    MatrixXf mat(2, 2);
    // clang-format off
    mat << 1, 2, 
           3, 4;
    // clang-format on

which adds a ton of unnecessary noise which does impair reading.

[1] https://eigen.tuxfamily.org/dox/group__TutorialAdvancedIniti...

>We all read through comment threads on HN where each is written in it's own style and nobody has a problem understanding it.

That's not true. Walls of texts get ignored or complained about. Grammar nazis show up if you use the wrong to/too.

If your typing on a phone autocomplete more or less enforces grammar and punctuation.

I'll take the tyranny of the linter tool over not having it at all (and I've had both). At least with my current project, it's single-handedly helped catch tricky React re-render bugs, because it warns me when I'm missing a dependency, or also warns me ahead of time if I'm likely to encounter a re-render every frame (and what's causing it), etc.

Also it's helped keep unused garbage out of the codebase also, which people tend to leave in there otherwise.

Also prettier has helped in me no longer reviewing MRs where every single line shows up in a file because their local machine has a different tab indent set or a different way to handle newlines (like with or without carriage returns, IIRC).

Sure it styles some things that aren't my preference, but I don't have to do it myself, it just automatically changes it all, so I can deal with it.

And if something is especially annoying or causes issues, I can usually get an exception added to the configuration, at least on my current team.

Symptom of nothing better to do, I have found ;)

Hard to picture someone who values their time blocking PRs on tiny stylistic nits.

When code formatters were new, they insisted on vertical in addition to horizontal spacing rules, and that pissed a lot of wise people off.

These days they are pretty good at preserving vertical separation if it already exists and adding it if it’s missing.

>> With woodworking, you can just do the thing. OK, I don't do woodworking myself, but both of my parents do, and I know that they don't spend their time bikeshedding or homogenizing their work.

This is why woodworking is actually a poor analogy for software development. A better analogy is carpentry. And when it comes to carpentry, it is much more important to ensure whatever you're building is extensible or follow certain specs. The cabinets you make, for example, need to fit into a certain space under or over the counter, and need to be homogenous to a large extent.

It seems like you're making a distinction between types of work.

For hobby or artisanal pursuits, homogeneity isn't the goal. Often the uniqueness is a feature. But for mass production or large coordinated efforts, uniqueness is a bug. You don't want your car to be manufactured by someone who just felt like a 3mm panel gap felt more right than the 4mm gap the specs called for. Standardization makes coordination easier and that's why some products are better when they are homogenous while others are better when they're allowed to be "creative."

> they don't spend their time bikeshedding or homogenizing their work.

They would if their woodworking projects spanned decades and involved thousands of other woodworkers.

"No pre-push linter" is the hill I'll die on.

Could you elaborate? My team is currently looking at adding a pre-push linter to replace the annoying CI linter.

Linters as gatekeepers are bad in my opinion, and ones that prevent you from pushing as pre-push hooks are the worst offenders.

My theory is that excessive linter rules might be a symptom of trying to compensate for the weaknesses of a programming language. I see it a lot in Python and JavaScript projects where the language gives very litte guarantees about anything.

If you use a programming language that affords some guarantees like Haskell or even just C#, people seem to be less interested in linters.

Linting reduces the expressiveness of a language so that a large team can have some consistency.

It’s not necessarily a weakness of the language.

Languages like Haskell, C#, and Java don’t have the same amount of expressiveness as js, python, or ruby, so they don’t benefit as much from a linter, though I know places that use one for C# to prevent usage of the ‘var’ keyword

I have that at my current place with var in Java.

And enforcing new lines on else or catch after the brace, completely different to the language guides.

It looks a fucking mess.

It’s okay to want more.

Reply on news.ycombinator.com