Comment by insanitybit
2 days ago
I've never had discussions about code formatting in PRs, this seems like a made up problem or something that predates my career.
2 days ago
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
3 replies →
> 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.
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.
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.
6 replies →
Yes, also at workplaces I saw these discussions in the past. These discussions almost completely disappeared when formatters became popular.
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.