4 ms·

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

by maratc 3mo ago

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.

dewey 3mo 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. 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.
- phoghed 3mo ago
  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
  - insanitybit 3mo ago
    Can you not read code if it uses single vs double quotes?
    - fatata123 3mo ago
      [dead]
    - dewey 3mo ago
      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.
      - insanitybit 3mo ago
        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.
    - 9dev 3mo ago
      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.
      - insanitybit 3mo ago
        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.
        9dev 3mo ago
        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.
  - yread 3mo ago
    That's exactly what a good cogwheel in the machine would say
  - maratc 3mo ago
    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.
    - refactor_master 3mo ago
      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.
      - phoghed 3mo ago
        I need a kitchen linter to highlight dishes red that my kids leave around rather than putting in the sink or dishwasher
      - maratc 3mo ago
        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.
- jghn 3mo ago
  > 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.
- coldtea 3mo 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.
- CrompyBlompers 3mo ago
  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/ https://github.com/golangci/golines/ 1: https://github.com/mvdan/gofumpt https://github.com/mvdan/gofumpt
- sennalen 3mo ago
  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.
  - kstrauser 3mo ago
    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.
    - zelphirkalt 3mo ago
      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.
      - kstrauser 3mo ago
        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.
- kristjansson 3mo ago
  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.
CuriouslyC 3mo ago
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.
- maratc 3mo ago
  See if you know where this leads before clicking on it: https://xkcd.com/208/ https://xkcd.com/208/
  - CuriouslyC 3mo ago
    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?
    - maratc 3mo ago
      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.
      - CuriouslyC 3mo ago
        \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.
        maratc 3mo ago
        > \bfoo\b will produce noisy results. Add a look-behind for '[' and a look-ahead for ']' and you'll be fine.
bigmadshoe 3mo ago
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.

by maratc 3mo ago

dewey 3mo 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. 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.

phoghed 3mo ago
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
- insanitybit 3mo ago
  Can you not read code if it uses single vs double quotes?
  - fatata123 3mo ago
    [dead]
  - dewey 3mo ago
    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.
    - insanitybit 3mo ago
      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.
  - 9dev 3mo ago
    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.
    - insanitybit 3mo ago
      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.
      - 9dev 3mo ago
        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.
- yread 3mo ago
  That's exactly what a good cogwheel in the machine would say
- maratc 3mo ago
  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.
  - refactor_master 3mo ago
    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.
    - phoghed 3mo ago
      I need a kitchen linter to highlight dishes red that my kids leave around rather than putting in the sink or dishwasher
    - maratc 3mo ago
      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.
jghn 3mo ago
> 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.
coldtea 3mo 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.
CrompyBlompers 3mo ago
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/ https://github.com/golangci/golines/ 1: https://github.com/mvdan/gofumpt https://github.com/mvdan/gofumpt
sennalen 3mo ago
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.
- kstrauser 3mo ago
  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.
  - zelphirkalt 3mo ago
    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.
    - kstrauser 3mo ago
      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.
kristjansson 3mo ago
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.

CuriouslyC 3mo ago

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.

maratc 3mo ago
See if you know where this leads before clicking on it: https://xkcd.com/208/ https://xkcd.com/208/
- CuriouslyC 3mo ago
  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?
  - maratc 3mo ago
    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.
    - CuriouslyC 3mo ago
      \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.
      - maratc 3mo ago
        > \bfoo\b will produce noisy results. Add a look-behind for '[' and a look-ahead for ']' and you'll be fine.

bigmadshoe 3mo ago

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.