3 ms·

>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 lo

by 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.
    - arein3 3y ago
      Better edit the comment and remove the email, as it can be scanned by crawlers and added to a spam list.
  - fireflash38 3y ago
    Imo, just sounds like someone mad that others can't recognize their "style" when reading code that's been through a formatter. Code is not just for style. You get no points for fancy spacing. You get no money for having being a "that guy who likes to format his args weirdly".
    - Pannoniae 3y ago
      If style didn't matter at all, we'd be writing assembly or bytecode. But we don't, because code is written for humans most importantly. Reducing the code down to basically the AST makes it lose important semantic meaning; which defeats the purpose of high-level languages.
- arein3 3y ago
  I suppose you never encountered git conflicts caused by differences in the autoformatter settings. Or a lot of changes without reason, making it more time consuming to find the real change in the commit diff log. I don't mind differences in code style. There is a standart called editorconfig, which IDEs support, which makes code style rules IDE independent. Actually if you have people with experience and professionals, they don't care about a specific code style rule, they don't care if they switch the code style from project to project, they just want a standart set of rules for the whole team so that there are no issues caused by different formatting styles.

by arein3 3y ago

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.
  - arein3 3y ago
    Better edit the comment and remove the email, as it can be scanned by crawlers and added to a spam list.
- fireflash38 3y ago
  Imo, just sounds like someone mad that others can't recognize their "style" when reading code that's been through a formatter. Code is not just for style. You get no points for fancy spacing. You get no money for having being a "that guy who likes to format his args weirdly".
  - Pannoniae 3y ago
    If style didn't matter at all, we'd be writing assembly or bytecode. But we don't, because code is written for humans most importantly. Reducing the code down to basically the AST makes it lose important semantic meaning; which defeats the purpose of high-level languages.
arein3 3y ago
I suppose you never encountered git conflicts caused by differences in the autoformatter settings. Or a lot of changes without reason, making it more time consuming to find the real change in the commit diff log. I don't mind differences in code style. There is a standart called editorconfig, which IDEs support, which makes code style rules IDE independent. Actually if you have people with experience and professionals, they don't care about a specific code style rule, they don't care if they switch the code style from project to project, they just want a standart set of rules for the whole team so that there are no issues caused by different formatting styles.