In my previous place, discussions on coding style were forbidden in PRs. It worked just fine.

Edit: one could also use single or double quotes in strings, and it didn't anger the grammar nazi bots as there were none.

Which gets rid of the discussion, but not the problem coding style rules are supposed to fix: Code looks the same, regardless of who wrote it. That's the whole point of code style guidelines like that as there's no functional reason for them.

That's why I like Go, every piece of code looks the same, there's one default enforced linter and this discussion (or discussion if discussion should be allowed or prohibited) doesn't even cross anyones mind.

Waiting patiently for the other person to produce a post hoc rationalization about why everybody’s code looking different is in fact a good thing

Can you not read code if it uses single vs double quotes?

You are not making the strongest point by using a relatively subjective rule like that. It includes indentation, how to structure functions and the parameters and many more that in sum make it very easy to jump between projects (Internal company projects, dependencies, other open source projects) without ever getting used to a new style. This makes reading and contributing very easy.

Compare that with other languages where you need to load a different set of prettier rules, code formatting tools and follow contribution guidelines on how things should look like depending on the opinion of the maintainers.

I've never found this to be the case having jumped companies a fair bit. I can switch programming languages easily enough, surely I can handle formatting.

I can - in fact, I have to, a lot more than I'd like - when someone makes changes with different code style settings in their IDE or tooling, and that affects unrelated parts of the code, and suddenly the PR contains tons of code that just looks subtly different but still does the same thing.

If sieving the spam from ham in code reviews is your thing, go have fun.

I personally prefer code that is automatically and unconditionally kept in the exact same shape, preserving only the intended changes to stop the team from wasting time on formatting or reviewing.

That seems like a problem caused by an autoformatted, not solved by one. Obviously having reviewable commits is a reasonable expectation but that doesn't seem like a justification at all.

Pretty much all tools developers use to write code format code to some extent while editing, but often with individual configuration knobs or default settings that are different between all ICs.

Having a single tool that runs before committing, ideally as a git hook, ensures a single, uniform style across all files touched.

That's exactly what a good cogwheel in the machine would say

My argument is more to the tune of "everybody’s code looking slightly different is not a problem in practice as long as I can read and understand it."

However since you've asked so nicely here you go: everybody’s code looking different is because all humans are different. It's what makes us human. I am very serious about my craftsmanship, and I bring my "humanity" to it: sometimes I include a cultural reference (as in the example above), or an internal joke in the name of a (very long) variable, or vent my frustration in a comment.

My first ten years of writing Python were uneventful; nobody commented about my style and I never commented about others'. With the advent of grammar nazi bots, everyone is supposed to now please them by writing completely bland code, which in my opinion degrades me from a craftsman to a code-monkey. This is dehumanising, in a certain sense.

But your choice of funny variable names is not a craft, and you’re not a craftsman if you think it matters. What matters is extensibility, maintainability and value delivered.

I care how the food tastes, not that the chef has a really cool Japanese knife and is really fast at cutting onions.

I need a kitchen linter to highlight dishes red that my kids leave around rather than putting in the sink or dishwasher

I think you miss the point, but using your foodie reference: would you rather go to a couple of Michelin restaurants -- where each piece brings a reflection of the chef, the geographic area, and what quality ingredients were available on that day -- or would you rather only eat at McDonald's for an experience that is extremely consistent across days, seasons, and continents?

Now imagine a chef who has a nice little restaurant but is now being sent a couple of "quality assurance" guys from McDonald's who tell him that his choice of potato variety for chips does not exactly conform to the "standards" defined at the mothership.

A chef in a michelin restaurant, unless he/she is the sole employee (very rare) is likely in charge of a team of line cooks and while they may get some time and place to experiment you better believe it will not be when preparing the chefs carefully curated menu and recipes for paying customers who have been on a reservation waitlist for months. Bob decided to cook the broccoli with a blowtorch and substituted some ingredients in table 9s dinner. There is a fire in the kitchen and the NYT food critic is going into anaphylactic shock but Bob at least feels like an artist so we will let it slide.

The hidden implication in your extension of the foodie analogy is that consistent food must have worse quality.

That's not true, and if anything in software having consistent software delivery makes it more likely to achieve Michelin-graded level of quality, not less.

But the formatting is not all that "delivery" stands for.

I've worked on great codebases that would produce thousands of linter errors (lowball estimation), and on shitty codebases that were 100% compliant.

The one day, your chef leaves, the food goes to shit and productivity/output/morale drops. When the new chef arrives, then everyone has to relearn everything.

Software shouldn't be bespoke and "artisan".

And here's where this abstraction breaks: when a programmer leaves, their code is not going anywhere.

The bigger problem is this: you want me to be a cog wheel, but I want to be an artist.

Then go be an artist and leave the rest of us to tend our well oiled machines.

I too want to be an artist, but I work in an economy that requires me to be an artist mostly in my off hours.

And honestly, this is such a weird hill to die on. Lint rules when automated are basically pure win in most scenarios, and for your example, just exclude the rule for this block.

> The bigger problem is this: you want me to be a cog wheel, but I want to be an artist.

Well, that's the ball game then. This isn't the industry to be an artist in, especially post-AI.

I think the artisanal code industry will exist. It will not be large and it will not pay well.

Take it to your employer then, not to us.

We want maintainable code we can quickly onboard in, and be able to modify and extend. Your artistry is getting in the way of other people getting stuff done.

I'd go so far as to argue that person to person differences are helpful to a reader. When I am dealing with a long term code base it's easy to develop a feel for who is responsible for different constructs without needing to rely on the git history. This gives me immediate information on what to expect.

It depends wildly on how one defines "slightly". If it overflows in the editor, then that's a problem IMO. But some people would say no. In PHP we often see this type of thing:

  $someArr = [
    'config' => [
      'system' => 'linux',
      ...
     ],
  ];

Versus:

  $someArr =
    [
      'config' =>
        [
          'system' => 'linux',
          ...
        ],
    ];

Well... option 2 uses both significantly more vertical space, and horizontal space. But it's technically PSR compliant. However, we really need standard formatting on this, because it's annoying.

> That's why I like Go, every piece of code looks the same, there's one default enforced linter and this discussion (or discussion if discussion should be allowed or prohibited) doesn't even cross anyones mind

I remember people saying this exact same thing about Python ~20 years ago.

>Which gets rid of the discussion, but not the problem coding style rules are supposed to fix: Code looks the same, regardless of who wrote it.

Which might be more overrated OCD than anything worth it. If you like that, you can add a formatter at the end of the chain or even just when reviewing.

There's a ton of variation in golang code, as gofmt is not opinionated enough. As evidenced by the existence of golines[0] or gofumpt[1].

0: https://github.com/golangci/golines/

1: https://github.com/mvdan/gofumpt

Is that really a problem that needs solving though? The easiest way to not spend time bikeshedding is to just not bikeshed. Don't make guidelines. Don't run tools to check them. Don't comment on them in PRs. None of it matters.

Historically, yes. At some point, one person who likes to work with narrow terminal windows gets fed up with long lines and starts reformatting stuff as they go. Another person with a widescreen editor hates looking at code clustered around the left edge of the screen gets fed up and starts reformatting stuff as they go. It's just a mess. You end up with PRs where it's hard to see the 3 things that changed because it contains 200 lines of "my IDE would prefer to format things this way instead".

I have never seen this not happen, barring using autoformatters. I think Go and Rust have had great success avoiding all these dumb arguments by having built-in opinionated formatters from nearly the beginning.

Aren't you supporting the GP's point though? If you auto-format all the things, they will likely not be right for people either, neither for the narrow terminal window, not for the widescreen full size window enjoyer. And there was energy spent on making it so, without it being a clear winner. Instead we could just be respectful and leave such things as they are, and not have to discuss this at all.

No. Auto-formatters have a way of getting people out of the mindset of arguing about it and just accepting that's the way it is. It's not that different from, say, using a compiled language instead of assembler. You and I might have differing ideas about how to write the best assembly code. If we standardize on C, it's likely neither of us will love the compiler's output, but short of outright bugs we'd move past that and go back to writing code.

The value isn't just in the lack of discussion, but in amplifying the signal to noise ratio of diffs. with ruff or gofmt or whatever, it’s pretty much guaranteed that a change of code is an intentional part of the proposed change. with multiple authors with variable code styles touching the same project, there is a much higher chance of a diff containing lines that preserve semantics but change the code.

Using a consistent string delimiter has value: if you search for ['foo'] you will find all instances of the string foo. With inconsistent delimiters, you better have a single canonical 'foo' in your project or you're going to run into problems.

When a string contains strange characters, how do you enforce the single consistent delimiter?

You probably haven't written diverse enough code.

See if you know where this leads before clicking on it: https://xkcd.com/208/

So your argument is that your freedom to use whatever string delimiter you want (remember that ''', """, ` and even weird unicode glyphs are valid in many languages) is worth forcing other engineers on the team to know all valid string delimiters and remember to use the right regex to account for all possible weirdo choices?

My argument is that searching for \bfoo\b will produce all the results you want.

Python was designed from the start so that 'foo' and "foo" are equal. It also worked like that for 30 years or so. This has not been an issue in these 30 years. But then someone came with an opinion that one of them is better than the other.

\bfoo\b will produce noisy results. People have been pushing linting rules that force a single consistent choice of string delimiters since at least 2010 when Python went from a cute academic language to a real industry workhorse.

> \bfoo\b will produce noisy results.

Add a look-behind for '[' and a look-ahead for ']' and you'll be fine.

The inverse is also true (speaking from PHP, I'm not 100% familiar with Python semantics). If we use '' where appropriate, then we know absolutely no escaping and no interpolation is done. That has value. If we use "" for everything, then we have to examine the string for interpolation or for escaping.

I would hate to work on that codebase. We learn to parse code more quickly over years of looking at code written with the same conventions and style. There’s a reason why Google are so serious about following their style guides.

Even better: if someone feels like the syntax must be different, they can pick it up at a centralized repository with more people that specialize in syntax.

Afterwards it will affect production code everywhere on the planet. :)

This is the way, and why I wrote https://pypi.org/project/ssort/. Unfortunately you need to follow it up with shameless self-promotion or it doesn't work.

I've never had discussions about code formatting in PRs, this seems like a made up problem or something that predates my career.

It's not by accident that tabs vs spaces is one of the stereotypical great debates in programming.

I've never seen this debate take place outside of internet forums, almost always as a joke. It's been about 15 years since I even remember it coming up much as a joke, frankly.

Yes, because the battles have been fought and spaces won

Okay, so if the battles are won why do I have to care? What is the point of having so many strict, enforced style rules if your exemplar has already been long dealt with?

One war was won bro, there are many more.

Pretend they don’t exist as much as you’d like, tell everyone their lived experience is wrong, that the tools arose from delusion and not any real world need, and that they benefit no one.

I’ll keep using them though, and never suffer from someone writing typescript with 4 spaces, leading commas, and no semicolons again.

I'm not saying that lived experiences are wrong, I'm saying that I don't believe that these problems would exist under the current software engineering culture to the degree that people seem to insist upon.

These used to happen all the time. In one (otherwise great) programming course in university you would even get points subtracted if you did not follow the lecturer's preferred style.

(I think that in their case it was partially because uniformity made correcting faster.)

At work? School isn't really representative.

Yes, also at workplaces I saw these discussions in the past. These discussions almost completely disappeared when formatters became popular.

Oh, absolutely. I started writing Python professionally in 2010. Whenever a new group of people started working on a Python project, one of the first things they had to decide was tabs versus spaces. Everyone would begin by saying that the question was unimportant and silly, but then immediately add a “but” followed by a detailed justification of their personal preference. That would lead to people spending two full days exchanging arguments and links to blog posts.

Worse, sometimes you would start working on a project without having that discussion first, only to discover a few days later that the code was failing because different people had different indentation settings in their IDEs, both regarding tabs versus spaces and the number of spaces. You would then have to pause the work, go back, have the discussion, and decide who was going to fix all the code committed so far.

This only stopped when linters became popular. They may be a little like vaccines: when they work, you do not see them working, so it is easy to forget what things were like before. But believe me, when they appeared, they were a breath of fresh air. We could finally focus on discussing the work rather than the conventions.

And tabs versus spaces is only one example. There used to be PR discussions about countless style issues throughout the entire lifetime of a project. That was not entirely unreasonable, because a consistent style genuinely makes a project easier to work on. But when every individual convention has to be negotiated by humans, it takes enormous amounts of energy and becomes tedious very quickly.

> only to discover a few days later that the code was failing because different people had different indentation settings in their IDEs, both regarding tabs versus spaces and the number of spaces.

yeah, why Guido got away with the "we don't need deliminators, white space is just fine" for so long has always baffled me.

Because somehow a special character that marks the start and end of a block is hard for people to understand??

I think that tabs vs spaces is a rather extreme example because it has unexpected parser semantics - that is, it's not a style choice. So I don't think it's actually relevant to a conversation about conventions/ style.

It definitely is relevant to a discussion about linters. And as I said on my comment - it's just an example, I mentioned other types of discussions as well.

I don't think it is because spaces vs tabs impacts semantics.

Since this is a long-standing, real-world problem that linters solved, how could it not be relevant to a discussion about the usefulness of linters?

And the choice of whether to use tabs or spaces does not affect semantics. It is purely a matter of style. Indentation using tabs and indentation using spaces work in exactly the same way.

Because the discussion is about style enforcement and you're talking about semantics enforcement. You may as well be talking about generator comprehensions vs list comprehensions - they're two totally different things semantically.

> It is purely a matter of style. Indentation using tabs and indentation using spaces work in exactly the same way.

This isn't true. It changes how the code can be interpreted by tooling, and it changes how Python interprets the code because it's whitespace sensitive. It's also invisible. It's such an extreme example, I don't think this is reasonable to bring into the conversation for style discussions.

Silicon Valley (the TV show) memed about it with its tabs vs spaces bit. It used to be a thing for sure. It has been a good 10 or 15 years since I had such a discussion. Automated linting and formatting tools largely killed it in my experience.

I think the culture has just shifted. I haven't even sniffed a whiff these conversations since roughly 15 years ago. I've never, ever seen them at work.

I also never have these conversations at work…because every repo uses a linter and the engineers are mature enough to recognize most of these debates as bikeshedding. Every once in a while someone will suggest turning on or enabling a new custom rule with some justification and there is a brief discussion and it is enabled or not. Outside of work in a consulting gig I didn’t have a linter in the codebase and the owner brought on a new engineer, he wrote if else statements all on one line no matter how long they were and removed spaces everywhere because he thought shorter code was better. He balked hard at any feedback about code style and I was told I couldn’t enforce code style or install a linter. I think you will surprised how much you care if someone with a truly weird style starts putting it in your codebase, I always told myself I didn’t before this. After more dumb waste of time clashes like that I quit the project. Now even personal projects get a linter :).

> this seems like a made up problem or something that predates my career

I can believe the latter, and I can assure you this was a Big Deal back in the day. There's a reason Go ships with gofmt, and gofmt was somewhat revolutionary for being a built-in "you gotta do it like this" back in the day.

What is "back in the day" here? I've been in this field for like 16 years.

Others may remember it differently, but I feel like things started to change somewhere between 2009 to 2012? People were still hand-indenting code back then, and your personal style felt like something you had a bit of ownership of or was a creative outlet for you. I think we are in a much better place now where the editor + a central config file owns the whole thing, and I'd be surprised to see a modern codebase where a formatter's defaults weren't being used.

> something that predates my career

That's because everybody uses linters nowadays, which was the original point.

I'm not convinced.

I've made comments if the formatting is egregious enough. This is a "bigger problem" in not-python, languages without significant whitespace. You can truly write some horrifying code that will compile just fine.

Dunno, now the workflow is like agent makes code changes, ruff complains, agent fixes complaints at the cost of code bloat, agent makes a PR, another agent reviews the PR, agent makes changes, PR is approved and merged. Nobody reads PRs anymore with the agentic development velocity.

> Nobody reads PRs anymore with the agentic development velocity.

Tokens are burnt, that's the most important part. And with more of the generated shitty code there will be more tokens spent in the future.

>The point of the "grammar nazi" bots is to focus on the actual problems: if a bot is deciding about linting, you don't have to waste brain power to discuss it in PRs.

And yet, as per the example, the bot force worse linting decisions, and even pushes towards more bugs (e.g. future readers missing the comment intention since it now applies to all 3).

the claim we are arguing here is not that “linters never make mistakes” it is that “linters are generally beneficial and avoid mostly useless debates we previously spent an inordinate amount of time on” Most linters have an escape hatch for exactly this which is usually a one line disable comment

And yet, a new argument surfaces about whether or not the linking should take place. Some people just like to argue :)

There is no point discussing these minutia, ever. Just ban discussing them in PRs and then you don't need an opinionated bot rife with false positives to "fix" them.