3 ms·

I found your comment insightful until the "(often substandard)" part. This betrays the rest of your comment. You start out saying how arguing specific indentati

I found your comment insightful until the "(often substandard)" part. This betrays the rest of your comment. You start out saying how arguing specific indentation style is superficial but then betray this with that comment. If it truly is superficial then it does not matter what you lock in as long as you lock it in. As with many things it's not actually a technical problem. It's a social problem. And it can work. Where I am right now for example we do have formatting locked in and enforced by linters. And it's not an issue there's no debate about it in regular PRs at all. The code formatter adjusts it and that's that. If you want to change it, create a PR that changes the rules and put a cross section of developers on said PR to discuss it. Happens from time to time but not often and works well.

Pannoniae 3y ago
I say "often substandard".... because, honestly, it just is. For example, breaking long logging lines into multiple lines decreases readability, but the formatter doesn't care because it only sees the max. line length and that's it. Same with breaking long function definitions: it doesn't consider what makes sense or what is readable, it just messes the code up. Similarly, some projects differentiate between single and double quotes (e.g. single quotes for data, double quotes for userstrings), and this just drives a tank over it. Or completely disallow tabs, even when it's necessary for accessibility, like with screen readers (not even PEP8 enforces spaces, but black decides to without a configuration option) Same with whitespace: it refuses you to add more than 1 (or 2, can't remember) empty lines inside a function, even when it would be more readable to space it out. I heavily disagree with the assumption that consistency is better than readability. I believe that people can be civilised and not change each other's code just for the sake of formatting nitpicks, only when they actually edit the code.
- tayo42 3y ago
  Black not being configurable and getting popular is lame. Every project should be able to argue once about style, what is important then just apply that going foward with a configurable style checker.
  - sixstringtheory 3y ago
    If it’s configurable, then it’s never settled. People will find reasons to want to change it, or someone new will come in that used a better config at their last job.
    - pyrale 3y ago
      > People will find reasons to want to change it, or someone new will come in that used a better config at their last job. This is fine. Discussing code style once in a while is not a problem. What's a problem is discussing it at every PR. Having to endure through asinine style errors that no one in your team chose or even agrees with is worse than spending a couple hours every 6 months discussing a rule or two.
      - stevelini 3y ago
        > Discussing code style once in a while is not a problem. What's a problem is discussing it at every PR. I worked a team where this happened. Black was a godsend
        Pannoniae 3y ago
        That just means your coworkers are anti-social... this masks the problem but the real solution is educating people so they won't be anti-social anymore and stop nitpicking about others' style.
        sixstringtheory 3y ago
        Teaching people to “just don’t be anti-social” is not the purview of people on a team trying to get work done, nor is it even possible in many or most cases.
georgemcbay 3y ago
The lack of debate over line-to-line code style (because it is enforced by a standard formatter) is one of the reasons I still enjoy using Go, and that's despite the fact that it doesn't use what was my preferred C-era brace style. Just absolutely eliminating it as something to worry or argue about is something a lot more languages could benefit from, IMO. And yes, while other languages have third-party formatting and linting tools that can enforce an agreed-upon standard, in the real world that just never works out as well (once a codebase grows beyond a couple of contributors) as having it be truly standardized in the language itself.
- kzrdude 3y ago
  I think go has the benefit of the syntax being simple enough that not as much debate is needed. That is a legitimate feature of the language, and why not enjoy it. This comes already from the design of the language, I would say. I'm comparing to Rust, and I'm not surprised that there are more different ways to format Rust and not always a way to make everyone happy.
- jeremyjh 3y ago
  > in the real world that just never works out as well (once a codebase grows beyond a couple of contributors) Can you elaborate on this? Once you have a linter/formatter in your CI loop, how does it stop working just because you have more contributors? My main project at work uses Elixir - which has a built in formatter - and Javascript - which doesn't. We use eslint for Javascript and haven't touched its config in years as devs come and go.

Pannoniae 3y ago

I say "often substandard".... because, honestly, it just is. For example, breaking long logging lines into multiple lines decreases readability, but the formatter doesn't care because it only sees the max. line length and that's it. Same with breaking long function definitions: it doesn't consider what makes sense or what is readable, it just messes the code up. Similarly, some projects differentiate between single and double quotes (e.g. single quotes for data, double quotes for userstrings), and this just drives a tank over it. Or completely disallow tabs, even when it's necessary for accessibility, like with screen readers (not even PEP8 enforces spaces, but black decides to without a configuration option) Same with whitespace: it refuses you to add more than 1 (or 2, can't remember) empty lines inside a function, even when it would be more readable to space it out. I heavily disagree with the assumption that consistency is better than readability. I believe that people can be civilised and not change each other's code just for the sake of formatting nitpicks, only when they actually edit the code.

tayo42 3y ago
Black not being configurable and getting popular is lame. Every project should be able to argue once about style, what is important then just apply that going foward with a configurable style checker.
- sixstringtheory 3y ago
  If it’s configurable, then it’s never settled. People will find reasons to want to change it, or someone new will come in that used a better config at their last job.
  - pyrale 3y ago
    > People will find reasons to want to change it, or someone new will come in that used a better config at their last job. This is fine. Discussing code style once in a while is not a problem. What's a problem is discussing it at every PR. Having to endure through asinine style errors that no one in your team chose or even agrees with is worse than spending a couple hours every 6 months discussing a rule or two.
    - stevelini 3y ago
      > Discussing code style once in a while is not a problem. What's a problem is discussing it at every PR. I worked a team where this happened. Black was a godsend
      - Pannoniae 3y ago
        That just means your coworkers are anti-social... this masks the problem but the real solution is educating people so they won't be anti-social anymore and stop nitpicking about others' style.
        sixstringtheory 3y ago
        Teaching people to “just don’t be anti-social” is not the purview of people on a team trying to get work done, nor is it even possible in many or most cases.

georgemcbay 3y ago

The lack of debate over line-to-line code style (because it is enforced by a standard formatter) is one of the reasons I still enjoy using Go, and that's despite the fact that it doesn't use what was my preferred C-era brace style. Just absolutely eliminating it as something to worry or argue about is something a lot more languages could benefit from, IMO. And yes, while other languages have third-party formatting and linting tools that can enforce an agreed-upon standard, in the real world that just never works out as well (once a codebase grows beyond a couple of contributors) as having it be truly standardized in the language itself.

kzrdude 3y ago
I think go has the benefit of the syntax being simple enough that not as much debate is needed. That is a legitimate feature of the language, and why not enjoy it. This comes already from the design of the language, I would say. I'm comparing to Rust, and I'm not surprised that there are more different ways to format Rust and not always a way to make everyone happy.
jeremyjh 3y ago
> in the real world that just never works out as well (once a codebase grows beyond a couple of contributors) Can you elaborate on this? Once you have a linter/formatter in your CI loop, how does it stop working just because you have more contributors? My main project at work uses Elixir - which has a built in formatter - and Javascript - which doesn't. We use eslint for Javascript and haven't touched its config in years as devs come and go.