8 ms·

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 believ

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.

Arainach 2y ago
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.
- 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 ago
    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.
  - 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.
makerdiety 2y ago
> 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.
- sokoloff 2y ago
  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.
  - swader999 2y ago
    That's my main concern, I want to review the changes, not formatting opinions.
    - worik 2y ago
      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?
- vbezhenar 2y ago
  What bot? You create a branch, you push button in github UI, merge request is created. There's no bot.
  - Shacklz 2y ago
    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.
meijer 2y ago
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.
- dartos 2y ago
  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
  - happymellon 2y ago
    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.
- hinkley 2y ago
  It’s okay to want more.
Shacklz 2y ago
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.
- josephg 2y ago
  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.
  - neon_electro 2y ago
    This is why linters are configurable; if your team doesn't care about consistent use of semicolons, ignore that linter. Right?
    - josephg 2y ago
      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.
swader999 2y ago
I'm just happy to have gone six years without wasting half a day a month debating about formatting or whims.
foobarian 2y ago
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:
- busterarm 2y ago
  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!
- resters 2y ago
  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?
  - foobarian 2y ago
    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.
    - kcrwfrd_ 2y ago
      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.
- beryilma 2y ago
CipherThrowaway 2y ago
> 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. Symptom of nothing better to do, I have found ;) Hard to picture someone who values their time blocking PRs on tiny stylistic nits.
cdchn 2y ago
"No pre-push linter" is the hill I'll die on.
- Cerium 2y ago
  Could you elaborate? My team is currently looking at adding a pre-push linter to replace the annoying CI linter.
  - cdchn 2y ago
    Linters as gatekeepers are bad in my opinion, and ones that prevent you from pushing as pre-push hooks are the worst offenders.
9dev 2y ago
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.
- nkozyra 2y ago
  > 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.
  - treflop 2y ago
    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.
- hinkley 2y ago
  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.
  - dfc 2y ago
InitialLastName 2y ago
> 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".
- JKCalhoun 2y ago
  > 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".
  - InitialLastName 2y ago
    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.
    - JKCalhoun 2y ago
      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?).
      - Izkata 2y ago
        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.
JKCalhoun 2y ago
> 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....
jimbokun 2y ago
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.
- hinkley 2y ago
  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.
- mbeddedartistry 2y ago
  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.”
  - jimbokun 2y ago
    If you want to sell your woodwork you would have similar issues.
    - consf 2y ago
      [dead]
- probably_wrong 2y ago
  > 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.
eddd-ddde 2y ago
> 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.
- plugin-baby 2y ago
  > 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.
- chasd00 2y ago
  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...
- tomjakubowski 2y ago
  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.
hinkley 2y ago
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.
cableshaft 2y ago
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.
shuntress 2y ago
> 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.
bumby 2y ago
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."
enraged_camel 2y ago
>> 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.
patrick451 2y ago
> 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__TutorialAdvancedInitialization.html https://eigen.tuxfamily.org/dox/group__TutorialAdvancedIniti...
- tayo42 2y ago
  >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.

Arainach 2y ago

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.

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

makerdiety 2y ago

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

sokoloff 2y ago
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.
- swader999 2y ago
  That's my main concern, I want to review the changes, not formatting opinions.
  - worik 2y ago
    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?
vbezhenar 2y ago
What bot? You create a branch, you push button in github UI, merge request is created. There's no bot.
- Shacklz 2y ago
  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.

meijer 2y ago

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.

dartos 2y ago
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
- happymellon 2y ago
  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.
hinkley 2y ago
It’s okay to want more.

Shacklz 2y ago

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.

josephg 2y ago
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.
- neon_electro 2y ago
  This is why linters are configurable; if your team doesn't care about consistent use of semicolons, ignore that linter. Right?
  - josephg 2y ago
    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.

swader999 2y ago

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

foobarian 2y ago

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:

busterarm 2y ago
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!
resters 2y ago
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?
- foobarian 2y ago
  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.
  - kcrwfrd_ 2y ago
    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.
beryilma 2y ago

CipherThrowaway 2y ago

> 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. Symptom of nothing better to do, I have found ;) Hard to picture someone who values their time blocking PRs on tiny stylistic nits.

cdchn 2y ago

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

Cerium 2y ago
Could you elaborate? My team is currently looking at adding a pre-push linter to replace the annoying CI linter.
- cdchn 2y ago
  Linters as gatekeepers are bad in my opinion, and ones that prevent you from pushing as pre-push hooks are the worst offenders.

9dev 2y ago

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.

nkozyra 2y ago
> 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.
- treflop 2y ago
  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.
hinkley 2y ago
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.
- dfc 2y ago

InitialLastName 2y ago

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

JKCalhoun 2y ago
> 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".
- InitialLastName 2y ago
  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.
  - JKCalhoun 2y ago
    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?).
    - Izkata 2y ago
      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.

JKCalhoun 2y ago

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

jimbokun 2y ago

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.

hinkley 2y ago
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.
mbeddedartistry 2y ago
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.”
- jimbokun 2y ago
  If you want to sell your woodwork you would have similar issues.
  - consf 2y ago
    [dead]
probably_wrong 2y ago
> 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.

eddd-ddde 2y ago

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

plugin-baby 2y ago
> 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.
chasd00 2y ago
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...
tomjakubowski 2y ago
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.

hinkley 2y ago

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.

cableshaft 2y ago

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.

shuntress 2y ago

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

bumby 2y ago

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

enraged_camel 2y ago

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

patrick451 2y ago

> 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__TutorialAdvancedInitialization.html https://eigen.tuxfamily.org/dox/group__TutorialAdvancedIniti...

tayo42 2y ago
>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.