4 ms·

This was the key line: > I eventually gave up on trying to make the formatted rust-fuse code look pretty, and settled for "consistent". It turns out that most

This was the key line: > I eventually gave up on trying to make the formatted rust-fuse code look pretty, and settled for "consistent". It turns out that most aspects of coding style are subjective and are fine once you get used to them. The *-fmt tools that are now the fashion get everyone past that initial stage of formatting things as you personally would and get you used to a common style. Maybe one person (the author of the style tool) is completely happy with the chosen style, but consistent is more important than personal preference on details.

arethuza 6y ago
One thing I've learned over the years using a lot of different languages is to pretty much ignore my initial reaction to syntax or formatting conventions for any given language - there is a pain period and then you get used to things and move on... Edit: I'm particularly thinking of PostScript, Lisp and Python - which on first impression seemed crazy but I actually learned to really like.
- rkangel 6y ago
  I have a similar thing when I work on a new codebase (or join a new company for that matter): make a note of all the pain points, but don't do anything with them for a few months. It'll turn out that a lot of them were for a good reason, but some of them won't be and the existing team has just got used to them ('missing stair'). That's why the notes are important, because you probably have too!
  - arethuza 6y ago
    Mind you - I have joined places that were genuinely crazy (no source control, no backups, deployment by RAID...) where some things needed fixed immediately. That was a long time ago though.
    - benji-york 6y ago
      > deployment by RAID I'd like to hear that story.
      - arethuza 6y ago
        The company supplied on-premise server 'appliances' for a particular market niche. To create a new deployment, find an existing server (usually at an existing customer), take out a mirrored RAID disk and replace it with a blank one. When mirroring complete put old one back in and take your new copy and use it in a new server for the new customer.... Repeatable build process, repeatable deployment process - who needs that when you have the power of RAID-1! <sob> Fortunately, it was a long time ago....
        ufmace 6y ago
        Wow. That's both amazing that somebody thought to do that and it worked, and terrifying that it became the official solution for production deployments.
bluejekyll 6y ago
> Maybe one person (the author of the style tool) is completely happy with the chosen style I remember there being quite a lot of community outreach to discuss pros and cons of all sorts of different rustfmt style options. All of them were very thoughtful, and made what I think has ended up with a set of decent compromises.
pornel 6y ago
This taboo of having opinions about code formatting shuts down legitimate criticism of rustfmt's design and implementation. There are cases where rustfmt is just bad. I'd argue "objectively" bad: • match arms are formatted individually, so nearly-identical arms can end up looking wildly differently if they hit different fuzzy logic thresholds. In Rust, enum variants aren't types, and macros can't see enum variants in the match context, so repetitive match arms are sometimes a necessary evil. • deletion of a line can fold a multi-line construct into a single line. This makes diffs bigger and harder to review. • rustfmt throws away any human influence on layout of code (short of sorting functions alphabetically). It doesn't merely change the boring bikeshedable mechanics like where the spaces go, but significantly rearranges how expressions are laid out and separated from each other. For example: let value = do().something().to().get().a_value_maybe() .or_else(|| some_error_handling_here)?; I think the code above is great, because the happy path is on one line, and error handling is on the other. Rustfmt intentionally erases that: let value = do().something().to().get().a_value_maybe().or_else(|| some_error_handling_here)?; That is IMHO bizarre. The value is what? Oh, there's spaghetti in the second line. Gofmt is way better. It fixes formatting errors it understands, but when there are multiple correct ways to format a piece of code, it leaves the higher-level structure as-is. OTOH Rustfmt has an overriding opinion on everything. Non-negotiable heuristics replace all common sense. There's no other production-quality formatter for Rust, so usage of rustfmt boils down to: 1. We must use something 2. Rustfmt is something 3. Therefore, we must use rustfmt

arethuza 6y ago

One thing I've learned over the years using a lot of different languages is to pretty much ignore my initial reaction to syntax or formatting conventions for any given language - there is a pain period and then you get used to things and move on... Edit: I'm particularly thinking of PostScript, Lisp and Python - which on first impression seemed crazy but I actually learned to really like.

rkangel 6y ago
I have a similar thing when I work on a new codebase (or join a new company for that matter): make a note of all the pain points, but don't do anything with them for a few months. It'll turn out that a lot of them were for a good reason, but some of them won't be and the existing team has just got used to them ('missing stair'). That's why the notes are important, because you probably have too!
- arethuza 6y ago
  Mind you - I have joined places that were genuinely crazy (no source control, no backups, deployment by RAID...) where some things needed fixed immediately. That was a long time ago though.
  - benji-york 6y ago
    > deployment by RAID I'd like to hear that story.
    - arethuza 6y ago
      The company supplied on-premise server 'appliances' for a particular market niche. To create a new deployment, find an existing server (usually at an existing customer), take out a mirrored RAID disk and replace it with a blank one. When mirroring complete put old one back in and take your new copy and use it in a new server for the new customer.... Repeatable build process, repeatable deployment process - who needs that when you have the power of RAID-1! <sob> Fortunately, it was a long time ago....
      - ufmace 6y ago
        Wow. That's both amazing that somebody thought to do that and it worked, and terrifying that it became the official solution for production deployments.

bluejekyll 6y ago

> Maybe one person (the author of the style tool) is completely happy with the chosen style I remember there being quite a lot of community outreach to discuss pros and cons of all sorts of different rustfmt style options. All of them were very thoughtful, and made what I think has ended up with a set of decent compromises.

pornel 6y ago

This taboo of having opinions about code formatting shuts down legitimate criticism of rustfmt's design and implementation. There are cases where rustfmt is just bad. I'd argue "objectively" bad: • match arms are formatted individually, so nearly-identical arms can end up looking wildly differently if they hit different fuzzy logic thresholds. In Rust, enum variants aren't types, and macros can't see enum variants in the match context, so repetitive match arms are sometimes a necessary evil. • deletion of a line can fold a multi-line construct into a single line. This makes diffs bigger and harder to review. • rustfmt throws away any human influence on layout of code (short of sorting functions alphabetically). It doesn't merely change the boring bikeshedable mechanics like where the spaces go, but significantly rearranges how expressions are laid out and separated from each other. For example: let value = do().something().to().get().a_value_maybe() .or_else(|| some_error_handling_here)?; I think the code above is great, because the happy path is on one line, and error handling is on the other. Rustfmt intentionally erases that: let value = do().something().to().get().a_value_maybe().or_else(|| some_error_handling_here)?; That is IMHO bizarre. The value is what? Oh, there's spaghetti in the second line. Gofmt is way better. It fixes formatting errors it understands, but when there are multiple correct ways to format a piece of code, it leaves the higher-level structure as-is. OTOH Rustfmt has an overriding opinion on everything. Non-negotiable heuristics replace all common sense. There's no other production-quality formatter for Rust, so usage of rustfmt boils down to: 1. We must use something 2. Rustfmt is something 3. Therefore, we must use rustfmt