4 ms·

This. Author chose two spaces per indent and proceeded to nest blocks 5 levels deep? Guess I have to run it through a code formatter now just to read it. Alter

This. Author chose two spaces per indent and proceeded to nest blocks 5 levels deep? Guess I have to run it through a code formatter now just to read it. Alternatively, author chose eight spaces per indent and proceeded to nest things? My tiled windows only have ~100 columns, thanks so much for breaking my workflow with your poor choices.

gpderetta 5y ago
But why not? These days reformatting on the fly is fast and easy. Especially if you enforce formatting conventions on commit (so you can automatically reformat into a canonical version).
- d110af5ccf 5y ago
  Because typically code will be read far more than it is written and by far more people than contributed to it. In many cases I won't have the relevant tooling installed let alone know how to use it because I don't use that language myself. (For example, a library written in Rust that exposes C bindings whose prebuilt artifact I might download and link against.) That being said, I 100% wholeheartedly approve of enforcing code formatting (among other things) on commit. Pre-commit hooks and linters are both awesome.
  - gpderetta 5y ago
    If you do not have the relevant tooling you can still read the canonical formatting. If you want custom formatting, I don't think that expecting your editor to reformat on the fly is a big ask. At the end of the day that exactly what tab proponents expect.
    - d110af5ccf 5y ago
      > If you do not have the relevant tooling you can still read the canonical formatting. Which is often unnecessarily difficult for whatever reason, hence my initial comment. Given that tabs already exist there's literally no reason not to use them other than to intentionally spite any future readers who don't agree with your preference for indentation width. > that exactly what tab proponents expect Because that capability is built into even the most primitive of text editors since forever. Per-language formatting, on the other hand, is most certainly not.
      - gpderetta 5y ago
        Using just tabs you end up with misaligned code. So you need a mix of tabs and spaces (i.e. smart tabs). But nobody sane [1] would do that by hand and would rely on their editor to do the indenting automatically. At this point just ask the editor to indent on demand. [1] I'm hyperbolic, sorry if you actually do that although I pity you.
- xupybd 5y ago
  Automated reformats cause big problems in version control. Every line appears to come from the reformat commit. So it's hard to see when the codes function was changed.
  - gpderetta 5y ago
    you format as part of the commit, not as a separate commit.
  - d110af5ccf 5y ago
    I believe what's being described is on the fly (ie uncommited) reformatting to suit individual reading preferences. Additional enforced autoformatting at the time of commit ensures that all version controlled code always conforms to the chosen style. Thus there are never any reformat commits unless the chosen style is modified.

gpderetta 5y ago

But why not? These days reformatting on the fly is fast and easy. Especially if you enforce formatting conventions on commit (so you can automatically reformat into a canonical version).

d110af5ccf 5y ago
Because typically code will be read far more than it is written and by far more people than contributed to it. In many cases I won't have the relevant tooling installed let alone know how to use it because I don't use that language myself. (For example, a library written in Rust that exposes C bindings whose prebuilt artifact I might download and link against.) That being said, I 100% wholeheartedly approve of enforcing code formatting (among other things) on commit. Pre-commit hooks and linters are both awesome.
- gpderetta 5y ago
  If you do not have the relevant tooling you can still read the canonical formatting. If you want custom formatting, I don't think that expecting your editor to reformat on the fly is a big ask. At the end of the day that exactly what tab proponents expect.
  - d110af5ccf 5y ago
    > If you do not have the relevant tooling you can still read the canonical formatting. Which is often unnecessarily difficult for whatever reason, hence my initial comment. Given that tabs already exist there's literally no reason not to use them other than to intentionally spite any future readers who don't agree with your preference for indentation width. > that exactly what tab proponents expect Because that capability is built into even the most primitive of text editors since forever. Per-language formatting, on the other hand, is most certainly not.
    - gpderetta 5y ago
      Using just tabs you end up with misaligned code. So you need a mix of tabs and spaces (i.e. smart tabs). But nobody sane [1] would do that by hand and would rely on their editor to do the indenting automatically. At this point just ask the editor to indent on demand. [1] I'm hyperbolic, sorry if you actually do that although I pity you.
xupybd 5y ago
Automated reformats cause big problems in version control. Every line appears to come from the reformat commit. So it's hard to see when the codes function was changed.
- gpderetta 5y ago
  you format as part of the commit, not as a separate commit.
- d110af5ccf 5y ago
  I believe what's being described is on the fly (ie uncommited) reformatting to suit individual reading preferences. Additional enforced autoformatting at the time of commit ensures that all version controlled code always conforms to the chosen style. Thus there are never any reformat commits unless the chosen style is modified.