8 ms·

One of the hills I am willing to die on is auto-formatting. Code formatting is easily automated to an acceptable level, and people's personal preferences are su

One of the hills I am willing to die on is auto-formatting. Code formatting is easily automated to an acceptable level, and people's personal preferences are subjective. I like to solve interesting problems, and concentrate on crafting high quality software. Manual code formatting contributes to neither of these disciplines. Code formatting is BORING robot work, not human work. Total pointless drudgery. Toiling away because you like your bracket with a different spacing is IDIOTIC. Run the formatter and move on.

chrisweekly 6y ago
Agreed. I adopted the Wes Bos approach (drive Prettier from ESLint) and it's fantastic.
- antigirl 6y ago
  Any links? I only use it for react. I found eslint auto fix works well enough for node etc
  - chrisweekly 6y ago
    https://github.com/wesbos/eslint-config-wesbos https://github.com/wesbos/eslint-config-wesbos
ianleeclark 6y ago
I agree with this wholeheartedly. Being introduced to gofmt a few years categorically eliminated a certain class of PR comments allowing PRs to be more focused on actual implications and logic.
necrotic_comp 6y ago
Not to mention that if multiple people work on a codebase over time, if a very large project gets very old (like 20 years old), having consistent formatting goes a long way in allowing people to understand code that they may not have context for.
pmiller2 6y ago
I agree with you, but I’m not gonna lie: you had me worried with your first sentence. :)
VectorLock 6y ago
Normally I agree with treating code as a means to an end rather than an end to itself but I take a certain enjoyment in crafting in some way aesthetically pleasing code as well. I even find that if the code is "ugly" that there frequently might be a more eloquent and objectively better way of doing things. And a little time hand formatting I think is worth it if you're maximizing understandability and readability. Not arguing about style is nice, but having to resort to this brutalist architecture style of code formatting doesn't seem great to me. "Its just holding people, who CARES what the building looks like!"
- a_t48 6y ago
  Consistent style is more important than each block of code being perfectly pretty. You can still argue aesthetics, but they need to be applied across the entire codebase. Never having to bother someone because their PR doesn't meet the formatting guidelines is well worth it.
  - waheoo 6y ago
    People at work nit: my code all the time. I just straight up ignore them. If they ask me why, I tell them to add an autoformat to our ci or shut the hell up. Fwiw, i use an auto formatter but its got problems with certain rules so i switch them off. The reason we dont have it turned on in ci is because these rules break code.
    - a_t48 6y ago
      Yeah, auto formatter (or at least format validation) is a must.
  - ergothus 6y ago
    > Consistent style is more important than each block of code being perfectly pretty "Pretty", yes, but we're literally talking about using language to communicate. Consistency taken to extremes is harmful to communication. I don't understand the worship that people have for consistency. STUPID inconsistencies are bad, yes, and yes, there are certainly arguments that about subjective matters that are a waste of time. But distilling everything down to the lowest common denominator of grunt-talking is very consistent and terrible communication. (Does that feel like a strawman? I'd love for it to be! Once people stop talking about consistency uber-alles we'll be discussing the things that I consider important.) Right now, the most common reaction is to dismiss any idea of communication through language as irrelevant, subjective, and a waste of time."
stimpson_j_cat 6y ago
Not to mention it dirties up version control. It's a lot easier to tell which _significant_ things changed from the last commit when you're scanning a diff and no formatting changes are highlighted.
- waheoo 6y ago
  Ive seen heaps of autoformatters dirty up version control. Mostly when theyre fussing about new lines. I kind of wish autoformatters would just ignore new lines and focus on indentation alone. It would certainly cut down on the over zealous rules. I also think formatting should be separate from linting but because they both require a parser people seem to think theyre the same thing.
  - SOLAR_FIELDS 6y ago
    Wouldn't having the autoformatter run as a pre-commit hook alleviate this issue? (This is assuming you had already cleaned up all of the currently checked in code with said autoformatter)
    - est31 6y ago
      Most autoformatters are under active development, and updates to them often causes changes in their behaviour. So you have to have all devs agree on the precise version of the formatter used, and even then you still need to do regular commits that contain nothing but a run of the newest version of the formatter on the codebase, which sadly destroys long term git blame.
      - cheez 6y ago
        this is a solved problem, pin your packages.
        est31 6y ago
        But you still have to update them every now and then otherwise you can't use new features of your language. Which gives you the issue of breakages again.
hartator 6y ago
I don’t know. I feel formatting choice can carry information and removing that information for conformity might be not worth it.
- pezo1919 6y ago
  Huge plus!
MoroCode 6y ago
Personally I vote to let people write code in the format they are most comfortable with and run the formatter as part of CI
- SeanDav 6y ago
  Not sure I agree. Most coding is maintenance. Far better to adapt to whatever the coding style convention is. I also believe that formatters should be "light-touch" and not have an opinion about every last thing. At that point I start thinking, "if you so smart, why don't you write the bloody code!"

chrisweekly 6y ago

Agreed. I adopted the Wes Bos approach (drive Prettier from ESLint) and it's fantastic.

antigirl 6y ago
Any links? I only use it for react. I found eslint auto fix works well enough for node etc
- chrisweekly 6y ago
  https://github.com/wesbos/eslint-config-wesbos https://github.com/wesbos/eslint-config-wesbos

ianleeclark 6y ago

I agree with this wholeheartedly. Being introduced to gofmt a few years categorically eliminated a certain class of PR comments allowing PRs to be more focused on actual implications and logic.

necrotic_comp 6y ago

Not to mention that if multiple people work on a codebase over time, if a very large project gets very old (like 20 years old), having consistent formatting goes a long way in allowing people to understand code that they may not have context for.

pmiller2 6y ago

I agree with you, but I’m not gonna lie: you had me worried with your first sentence. :)

VectorLock 6y ago

Normally I agree with treating code as a means to an end rather than an end to itself but I take a certain enjoyment in crafting in some way aesthetically pleasing code as well. I even find that if the code is "ugly" that there frequently might be a more eloquent and objectively better way of doing things. And a little time hand formatting I think is worth it if you're maximizing understandability and readability. Not arguing about style is nice, but having to resort to this brutalist architecture style of code formatting doesn't seem great to me. "Its just holding people, who CARES what the building looks like!"

a_t48 6y ago
Consistent style is more important than each block of code being perfectly pretty. You can still argue aesthetics, but they need to be applied across the entire codebase. Never having to bother someone because their PR doesn't meet the formatting guidelines is well worth it.
- waheoo 6y ago
  People at work nit: my code all the time. I just straight up ignore them. If they ask me why, I tell them to add an autoformat to our ci or shut the hell up. Fwiw, i use an auto formatter but its got problems with certain rules so i switch them off. The reason we dont have it turned on in ci is because these rules break code.
  - a_t48 6y ago
    Yeah, auto formatter (or at least format validation) is a must.
- ergothus 6y ago
  > Consistent style is more important than each block of code being perfectly pretty "Pretty", yes, but we're literally talking about using language to communicate. Consistency taken to extremes is harmful to communication. I don't understand the worship that people have for consistency. STUPID inconsistencies are bad, yes, and yes, there are certainly arguments that about subjective matters that are a waste of time. But distilling everything down to the lowest common denominator of grunt-talking is very consistent and terrible communication. (Does that feel like a strawman? I'd love for it to be! Once people stop talking about consistency uber-alles we'll be discussing the things that I consider important.) Right now, the most common reaction is to dismiss any idea of communication through language as irrelevant, subjective, and a waste of time."

stimpson_j_cat 6y ago

Not to mention it dirties up version control. It's a lot easier to tell which _significant_ things changed from the last commit when you're scanning a diff and no formatting changes are highlighted.

waheoo 6y ago
Ive seen heaps of autoformatters dirty up version control. Mostly when theyre fussing about new lines. I kind of wish autoformatters would just ignore new lines and focus on indentation alone. It would certainly cut down on the over zealous rules. I also think formatting should be separate from linting but because they both require a parser people seem to think theyre the same thing.
- SOLAR_FIELDS 6y ago
  Wouldn't having the autoformatter run as a pre-commit hook alleviate this issue? (This is assuming you had already cleaned up all of the currently checked in code with said autoformatter)
  - est31 6y ago
    Most autoformatters are under active development, and updates to them often causes changes in their behaviour. So you have to have all devs agree on the precise version of the formatter used, and even then you still need to do regular commits that contain nothing but a run of the newest version of the formatter on the codebase, which sadly destroys long term git blame.
    - cheez 6y ago
      this is a solved problem, pin your packages.
      - est31 6y ago
        But you still have to update them every now and then otherwise you can't use new features of your language. Which gives you the issue of breakages again.

hartator 6y ago

I don’t know. I feel formatting choice can carry information and removing that information for conformity might be not worth it.

pezo1919 6y ago
Huge plus!

MoroCode 6y ago

Personally I vote to let people write code in the format they are most comfortable with and run the formatter as part of CI

SeanDav 6y ago
Not sure I agree. Most coding is maintenance. Far better to adapt to whatever the coding style convention is. I also believe that formatters should be "light-touch" and not have an opinion about every last thing. At that point I start thinking, "if you so smart, why don't you write the bloody code!"