7 ms·

From what I've seen so far, people love debating code style. The main problem is that those programmers mostly care about superficial syntax and don't actually

From what I've seen so far, people love debating code style. The main problem is that those programmers mostly care about superficial syntax and don't actually care about code readability or design. They just go for the lowest hanging fruit and criticise variable naming or whitespace because it is easy; they don't talk about the object graph or the event lifecycle of the program, because that's hard. A very common thing I see nowadays is a forced adoption of gofmt/black/whatever, hoping it would solve the obsession with the formatting. However, this just locks in a (often substandard) coding style and removes any kind of personality from the code. This is good if you are a manager trying to treat your employees as fungible units of work, but is bad for actually maintaining a codebase. Also, it doesn't stop obsession with style, it just forces a specific style on everyone which most of the time, everyone slightly hates. This is a really good article which summarises the problem way better than me. https://luminousmen.com/post/my-unpopular-opinion-about-black-code-formatter https://luminousmen.com/post/my-unpopular-opinion-about-blac...

eyelidlessness 3y ago
> From what I've seen so far, people love debating code style. In my experience with people who seemed to confirm this, the opposite turned out to be true. I spent an inordinate amount of time configuring linting and formatting to suit their tastes, to minimize any formatting subjectivity in code review. Their reviews got a lot more substantive and valuable pretty much immediately because their formatting concerns were evidently close enough to solved that they could pay attention to what the code actually did. I’ve had similar success adopting formatting that no one likes just because it’s opinionated and no one gets to dispute it because they couldn’t if they wanted to without diverting resources to a new tool. Now we’re all unhappy with the formatting and still happy to be reviewing actual substance. When the bad formatting gets in the way, it’s trivial to ask the question “is this just a whitespace change?” and everyone groans for a second, agrees that it is, and gets on with life. And when there’s any remaining style considerations (oh you like, or don’t like, reduce?) that’s a much smaller space of style concerns to negotiate and settle.
- Pannoniae 3y ago
  I think this is just accommodating anti-social behaviour, IMO. I think the correct choice of action is simply rooting the problem out by penalising comments about style on code review, so they focus on the substance of the code instead. Yes, this will require a period of uncomfortability while everyone gets used to each other's varied code styles, but it promotes a much more healthier atmosphere than the "suck it up" approach of unifying all code. That doesn't solve the problem, that just masks it by putting the code through a shredder so style gets lost.
  - bluGill 3y ago
    A consistent style is useful. It doesn't matter much what it is, but consistency means you can jump into unfamiliar code and not get misled by a different style that makes some block not appear how it actually functions.
    - zabzonk 3y ago
      > penalising comments about style on code review how exactly do you do that "penalising"?
      - Pannoniae 3y ago
        The same way as you do it if people commit on the wrong branch, or commit SQL concatenated with plaintext, or if they are toxic towards a coworker...
  - eyelidlessness 3y ago
    I have a ton of code style preferences that I’m thrilled to put on the back burner to accomplish really much more important things with my team. I can express my individuality and let my whitespace and brace freak flag fly on personal projects, and I can even have more energy to get those adopted into core work if I want to, because my daily work isn’t burdened by formatting preference taking away from much more important concerns like whether the thing actually works, has acceptable performance and usability and accessibility characteristics, and can be maintained on a continuous basis. It’s not that anyone else has felt stifled by this either. Everyone everyone contributing has welcomed the automated formatting dictator. We’ve all felt the benefit of not focusing review on stuff that doesn’t impact users. If you really want to express yourself in code formatting, go wild on your own time and enjoy the free time you have for it by not putting it in the middle of otherwise meaningful work.
tharkun__ 3y ago
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.
jvans 3y ago
it's a classic bike shedding exercise: https://en.wikipedia.org/wiki/Law_of_triviality https://en.wikipedia.org/wiki/Law_of_triviality
BurningFrog 3y ago
Unfortunately, variable naming is one of the most important parts of writing software.
__loam 3y ago
Code should not have personality. If you're working in a massive code base and people can tell you wrote code, that's probably an indictment on your code more than whatever style the company has chosen to use. Homogeneous code bases are the goal.
- Pannoniae 3y ago
  Only if you are an employer who wants to treat programmers interchangeably..... as a programmer, you have zero reason to do that. If all the codebase is homogenous, you can be replaced way easier, which is probably not what you want.
  - epgui 3y ago
    If your code style is what gives you the feeling of security at work… Well that’s a bit sad and I’m not convinced a linter can be blamed for anyone losing their jobs.
    - Pannoniae 3y ago
      No, mostly not. Doing my job properly gives me job security for the most part - but this is one of the things where I don't see any benefit for yourself, there is only a benefit for your employer. Of course, I'm not advocating writing cryptic undocumented obfuscated mess (that's just plain unethical, even if it's "good" for you), but coding in a "standard" style just benefits your employer, not you. It just means you are more easily replaceable without any benefit for you. You won't learn more from doing it, you won't gain any skills or anything.
      - LeafItAlone 3y ago
        > It just means you are more easily replaceable without any benefit for you What does this even mean? Companies don’t (well, shouldn’t) hire developers to just write code. They hire them to solve problems. I’m not going to more easily replaced because my code follows the same styles as others, if I am the one solving the problems they have.
KronisLV 3y ago
> However, this just locks in a (often substandard) coding style and removes any kind of personality from the code. This is good if you are a manager trying to treat your employees as fungible units of work, but is bad for actually maintaining a codebase. Is it bad, though? Having most of the code in the codebase look and read consistently feels like a good thing, even if that's not the style that you'd personally prefer. Especially if the formatter does its thing whenever you save a file.
- Pannoniae 3y ago
  If you want to be treated interchangeably to everyone else in the industry, yes. Otherwise, I don't think that's a good thing for you as a programmer
benrutter 3y ago
I definitely agree that Black (which I love) is pretty overrated in the number of problems people think it will solve for them. But I just don't get this view > removes any kind of personality from the code What kind of personality comes from things like pefering " over '; having tabs over spaces; having n spaces between class methods? For me, those things are essentially meaningless but nice to have consistency on. Code personality, and a large part of readability comes from things like: - variable / class names - functional vs oop problem solving - type use - custom data structures or not etc None of those have are locked down or touched by a lint tool like Black. Use it or don't, but you'll have plenty of personality in your code either way.
- Pannoniae 3y ago
  "Consistency is the most important" seems to be an axiom... "having n spaces between class methods" is definitely *not* meaningless. It affects code readability and black has very opionated (and often inappropriate) ideas about what counts as "readable" whitespace. When you raise that problem with people, they always say "well too bad, you should write shorter functions instead", which just introduces another layer of opinionatedness.
- kzrdude 3y ago
  That's not the interesting "personality". I think the formatting tools bring in something completely different: code layouts that you would never write by hand. I don't like that. Code should be a transparent interface, you write something and it becomes part of the program. With code formatting it becomes, you input something into the source code, you transform it with the tool, and then it's done. We sort of lose the brain-hand-program connection. As an example I randomly found this code snippet of rust imports. To reproduce this by hand would be like writing JSON by hand - I'm referring to the nesting, bracketing and sorting. This is the lack of personality: no longer writing code by hand, but with tools. use core::fmt; use std::{ alloc::{GlobalAlloc, System}, cell::UnsafeCell, cmp, fmt::Write, marker::PhantomData, sync::{ atomic::{AtomicBool, Ordering}, Mutex, }, time::Duration, }; use serde::{ de::{self, SeqAccess, Visitor}, Deserialize, Deserializer, Serialize, };
arein3 3y ago
>A very common thing I see nowadays is a forced adoption of gofmt/black/whatever, hoping it would solve the obsession with the formatting. However, this just locks in a (often substandard) coding style and removes any kind of personality from the code. This is good if you are a manager trying to treat your employees as fungible units of work, but is bad for actually maintaining a codebase. Also, it doesn't stop obsession with style, it just forces a specific style on everyone which most of the time, everyone slightly hates. This is so wrong. There is no reason to not have a standart for formatting code when working in a team.
- Pannoniae 3y ago
  There are good reasons for not having a standard code formatting style in a team. They might be ones you don't agree with, but saying there are no good reasons is IMO a bit disingenuous. With mature team members, it's perfectly possible to respect each other's style and if executed well, it can have advantages such as being able to very quickly identify who wrote something (who to pester about something), making readability decisions locally instead of globally and benefits like that. Of course, that requires a team with emotional maturity, which is I get, not very common in the software industry.
  - benrutter 3y ago
    Reading this and your other comments I have two very conflicting vibes that I: 1. Hard disagree on the idea of multiple styles in a single codebase and think being able to identify writers of code by style rather than version control sounds like madness incarnate. 2. Massively want to read a blog post or something from you about your ideas on code style. Sounds like you have some pretty valid and well thought out ideas justying a philosophy of code style I've never heard supported before (I think normally disparate code styles in a code base would get interpreted as a code smell rather than a positive)
    - Pannoniae 3y ago
      Hi! I don't have a website or a blogpost or anything, to be honest. If you want to chat about it, I'm happy to - my Discord is on my profile, my email is prisznyak.zsombor@gmail.com , or if you want to communicate with some other platform, let me know.
jwmoz 3y ago
black is brilliant and should be used on all Python projects.
Volrath89 3y ago
But we _are_ fungible. At least 99% of developers in 99% of projects. Management is right in trying to remove “personality” imo.
- Pannoniae 3y ago
  I mean, you are right.... But as programmers, shouldn't you try to be less replaceable? Have unique skills or methods which can be valued, instead of being a generic hotswappable code monkey. I don't really understand your logic - why is management right for removing personality? Of course, from a programmer's perspective, not from the manager's perspective.
  - Volrath89 3y ago
    Being able to use generic hotswappable code monkeys would be the wet dream of corporate executives. Imagine being able to scale or shrink your dev work force on demand, as if we were AWS instances. Actually this is the selling point of companies like Accenture or Globant, no wonder they have been so successful. From a dev pov, making sure you are easily replaceable means that you could also find a new job easily. So it’s not all bad.
thiht 3y ago
> it just forces a specific style on everyone which most of the time, everyone slightly hates. Just stop caring about useless stuff, gee… this is what the code review pyramid about, focus your efforts and care on important stuff, not irrelevant details. Auto formatted code is the best thing that happened in the last few years. I don’t care that it doesn’t show the « personality of the dev who wrote it », I want consistent code. > but is bad for actually maintaining a codebase Absolutely not.

eyelidlessness 3y ago

> From what I've seen so far, people love debating code style. In my experience with people who seemed to confirm this, the opposite turned out to be true. I spent an inordinate amount of time configuring linting and formatting to suit their tastes, to minimize any formatting subjectivity in code review. Their reviews got a lot more substantive and valuable pretty much immediately because their formatting concerns were evidently close enough to solved that they could pay attention to what the code actually did. I’ve had similar success adopting formatting that no one likes just because it’s opinionated and no one gets to dispute it because they couldn’t if they wanted to without diverting resources to a new tool. Now we’re all unhappy with the formatting and still happy to be reviewing actual substance. When the bad formatting gets in the way, it’s trivial to ask the question “is this just a whitespace change?” and everyone groans for a second, agrees that it is, and gets on with life. And when there’s any remaining style considerations (oh you like, or don’t like, reduce?) that’s a much smaller space of style concerns to negotiate and settle.

Pannoniae 3y ago
I think this is just accommodating anti-social behaviour, IMO. I think the correct choice of action is simply rooting the problem out by penalising comments about style on code review, so they focus on the substance of the code instead. Yes, this will require a period of uncomfortability while everyone gets used to each other's varied code styles, but it promotes a much more healthier atmosphere than the "suck it up" approach of unifying all code. That doesn't solve the problem, that just masks it by putting the code through a shredder so style gets lost.
- bluGill 3y ago
  A consistent style is useful. It doesn't matter much what it is, but consistency means you can jump into unfamiliar code and not get misled by a different style that makes some block not appear how it actually functions.
  - zabzonk 3y ago
    > penalising comments about style on code review how exactly do you do that "penalising"?
    - Pannoniae 3y ago
      The same way as you do it if people commit on the wrong branch, or commit SQL concatenated with plaintext, or if they are toxic towards a coworker...
- eyelidlessness 3y ago
  I have a ton of code style preferences that I’m thrilled to put on the back burner to accomplish really much more important things with my team. I can express my individuality and let my whitespace and brace freak flag fly on personal projects, and I can even have more energy to get those adopted into core work if I want to, because my daily work isn’t burdened by formatting preference taking away from much more important concerns like whether the thing actually works, has acceptable performance and usability and accessibility characteristics, and can be maintained on a continuous basis. It’s not that anyone else has felt stifled by this either. Everyone everyone contributing has welcomed the automated formatting dictator. We’ve all felt the benefit of not focusing review on stuff that doesn’t impact users. If you really want to express yourself in code formatting, go wild on your own time and enjoy the free time you have for it by not putting it in the middle of otherwise meaningful work.

tharkun__ 3y ago

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.

jvans 3y ago

it's a classic bike shedding exercise: https://en.wikipedia.org/wiki/Law_of_triviality https://en.wikipedia.org/wiki/Law_of_triviality

BurningFrog 3y ago

Unfortunately, variable naming is one of the most important parts of writing software.

__loam 3y ago

Code should not have personality. If you're working in a massive code base and people can tell you wrote code, that's probably an indictment on your code more than whatever style the company has chosen to use. Homogeneous code bases are the goal.

Pannoniae 3y ago
Only if you are an employer who wants to treat programmers interchangeably..... as a programmer, you have zero reason to do that. If all the codebase is homogenous, you can be replaced way easier, which is probably not what you want.
- epgui 3y ago
  If your code style is what gives you the feeling of security at work… Well that’s a bit sad and I’m not convinced a linter can be blamed for anyone losing their jobs.
  - Pannoniae 3y ago
    No, mostly not. Doing my job properly gives me job security for the most part - but this is one of the things where I don't see any benefit for yourself, there is only a benefit for your employer. Of course, I'm not advocating writing cryptic undocumented obfuscated mess (that's just plain unethical, even if it's "good" for you), but coding in a "standard" style just benefits your employer, not you. It just means you are more easily replaceable without any benefit for you. You won't learn more from doing it, you won't gain any skills or anything.
    - LeafItAlone 3y ago
      > It just means you are more easily replaceable without any benefit for you What does this even mean? Companies don’t (well, shouldn’t) hire developers to just write code. They hire them to solve problems. I’m not going to more easily replaced because my code follows the same styles as others, if I am the one solving the problems they have.

KronisLV 3y ago

> However, this just locks in a (often substandard) coding style and removes any kind of personality from the code. This is good if you are a manager trying to treat your employees as fungible units of work, but is bad for actually maintaining a codebase. Is it bad, though? Having most of the code in the codebase look and read consistently feels like a good thing, even if that's not the style that you'd personally prefer. Especially if the formatter does its thing whenever you save a file.

Pannoniae 3y ago
If you want to be treated interchangeably to everyone else in the industry, yes. Otherwise, I don't think that's a good thing for you as a programmer

benrutter 3y ago

I definitely agree that Black (which I love) is pretty overrated in the number of problems people think it will solve for them. But I just don't get this view > removes any kind of personality from the code What kind of personality comes from things like pefering " over '; having tabs over spaces; having n spaces between class methods? For me, those things are essentially meaningless but nice to have consistency on. Code personality, and a large part of readability comes from things like: - variable / class names - functional vs oop problem solving - type use - custom data structures or not etc None of those have are locked down or touched by a lint tool like Black. Use it or don't, but you'll have plenty of personality in your code either way.

Pannoniae 3y ago
"Consistency is the most important" seems to be an axiom... "having n spaces between class methods" is definitely *not* meaningless. It affects code readability and black has very opionated (and often inappropriate) ideas about what counts as "readable" whitespace. When you raise that problem with people, they always say "well too bad, you should write shorter functions instead", which just introduces another layer of opinionatedness.
kzrdude 3y ago
That's not the interesting "personality". I think the formatting tools bring in something completely different: code layouts that you would never write by hand. I don't like that. Code should be a transparent interface, you write something and it becomes part of the program. With code formatting it becomes, you input something into the source code, you transform it with the tool, and then it's done. We sort of lose the brain-hand-program connection. As an example I randomly found this code snippet of rust imports. To reproduce this by hand would be like writing JSON by hand - I'm referring to the nesting, bracketing and sorting. This is the lack of personality: no longer writing code by hand, but with tools. use core::fmt; use std::{ alloc::{GlobalAlloc, System}, cell::UnsafeCell, cmp, fmt::Write, marker::PhantomData, sync::{ atomic::{AtomicBool, Ordering}, Mutex, }, time::Duration, }; use serde::{ de::{self, SeqAccess, Visitor}, Deserialize, Deserializer, Serialize, };

arein3 3y ago

>A very common thing I see nowadays is a forced adoption of gofmt/black/whatever, hoping it would solve the obsession with the formatting. However, this just locks in a (often substandard) coding style and removes any kind of personality from the code. This is good if you are a manager trying to treat your employees as fungible units of work, but is bad for actually maintaining a codebase. Also, it doesn't stop obsession with style, it just forces a specific style on everyone which most of the time, everyone slightly hates. This is so wrong. There is no reason to not have a standart for formatting code when working in a team.

Pannoniae 3y ago
There are good reasons for not having a standard code formatting style in a team. They might be ones you don't agree with, but saying there are no good reasons is IMO a bit disingenuous. With mature team members, it's perfectly possible to respect each other's style and if executed well, it can have advantages such as being able to very quickly identify who wrote something (who to pester about something), making readability decisions locally instead of globally and benefits like that. Of course, that requires a team with emotional maturity, which is I get, not very common in the software industry.
- benrutter 3y ago
  Reading this and your other comments I have two very conflicting vibes that I: 1. Hard disagree on the idea of multiple styles in a single codebase and think being able to identify writers of code by style rather than version control sounds like madness incarnate. 2. Massively want to read a blog post or something from you about your ideas on code style. Sounds like you have some pretty valid and well thought out ideas justying a philosophy of code style I've never heard supported before (I think normally disparate code styles in a code base would get interpreted as a code smell rather than a positive)
  - Pannoniae 3y ago
    Hi! I don't have a website or a blogpost or anything, to be honest. If you want to chat about it, I'm happy to - my Discord is on my profile, my email is prisznyak.zsombor@gmail.com , or if you want to communicate with some other platform, let me know.

jwmoz 3y ago

black is brilliant and should be used on all Python projects.

Volrath89 3y ago

But we _are_ fungible. At least 99% of developers in 99% of projects. Management is right in trying to remove “personality” imo.

Pannoniae 3y ago
I mean, you are right.... But as programmers, shouldn't you try to be less replaceable? Have unique skills or methods which can be valued, instead of being a generic hotswappable code monkey. I don't really understand your logic - why is management right for removing personality? Of course, from a programmer's perspective, not from the manager's perspective.
- Volrath89 3y ago
  Being able to use generic hotswappable code monkeys would be the wet dream of corporate executives. Imagine being able to scale or shrink your dev work force on demand, as if we were AWS instances. Actually this is the selling point of companies like Accenture or Globant, no wonder they have been so successful. From a dev pov, making sure you are easily replaceable means that you could also find a new job easily. So it’s not all bad.

thiht 3y ago

> it just forces a specific style on everyone which most of the time, everyone slightly hates. Just stop caring about useless stuff, gee… this is what the code review pyramid about, focus your efforts and care on important stuff, not irrelevant details. Auto formatted code is the best thing that happened in the last few years. I don’t care that it doesn’t show the « personality of the dev who wrote it », I want consistent code. > but is bad for actually maintaining a codebase Absolutely not.