6 ms·

> I eventually gave up on trying to make the formatted rust-fuse code look pretty, and settled for "consistent". Even though it's a bit ugly, this is a big win

> I eventually gave up on trying to make the formatted rust-fuse code look pretty, and settled for "consistent". Even though it's a bit ugly, this is a big win. As for why it does this, from my experience, rust-fmt will try to keep lines under a column limit but not greedily. e.g. if a params list would extend past the limit, then all params get a newline. It seems to try to balance horizontal estate and vertical estate and I've become used to that (even though it is inconsistent at times). Any formatting rule is going to fall over eventually. Rust-fmt seems to make sane choices the majority of the time.

cgrealy 6y ago
Consistency > prettiness
- berkut 6y ago
  Is it just prettiness though? When I worked in the defence industry (~15 years ago now), a lot of the coding standards for C/C++ (which was starting to be used more and more over ADA at the time) were very strict on the matching alignment of things like open / closing braces, so things like hanging braces were not allowed, both opening and closing braces had to be on their own lines. The argument behind this was it made the code clearer, and more easy to match clauses / scoping - in a way arguing it was "safer" in terms of interpretation of the code.
  - hurrrrrrrr 6y ago
    Maybe, maybe not. Is the potential benefit even worth fighting over? Style is just full of so many subjective details that every discussion ends in. And everybody has their favorite it's un-fucking-readable. My oppinion converged on "Fight it out and tell me what options in $formatter I need to set. Don't even tell me reasonings, just the options. leaves room". I'd rather drink coffee than have the next horizontal real estate vs. parameter alignment debate. The argument to match clauses/scoping for example is weird in a world where a formatter automatically applies indentation. It might make sense when you have to manually check them on print-outs without an Editor. I'd argue GNU style fulfills that role even better or Horstmann if you care about vertical real estate (or be daring and combine the two). And now everyone hates me.
    - berkes 6y ago
      I lean to the other side. In a way that I tell the requester "you better have some really, really good reason for wasting my time on this". Hell, I've even had a new hire prepare an entire presentation to convince us to change the line-length to something different than "The Language Standard". "We follow the language standard" and if you don't like it, convince upstream (This was Rubocop/Ruby) is another one I've used in the past. Naturally both people just gave up. There really is a better way to spend time than on tuning and tweaking a linter. Nearly all linters have some way to document and define very local exceptions for that case when some external__dependency_IsMxing_camel_case or whatever.
- shmerl 6y ago
  That depends on how ugly that consistency is.
ncmncm 6y ago
When I worked for Ian Taylor (one of the creators of Go) it was a firing offense to waste time lining up columns or parentheses. Petty arranging is a waste of valuable time, time stolen from your employer if you have one. Just a one-unit indent provides all the information you need to convey to the reader. Rust's formatter not making up artificial alignment columns is the best thing about it.
qchris 6y ago
Just in case anyone's not familiar with it, I figured it's worth pointing that rustfmt is also really customizable, using a `rustfmt.toml` file in the source directory. It might take a little time to get right, but it's not as if you're stuck with the default options, and a .toml file is pretty easy to play around with. [1] https://rust-lang.github.io/rustfmt/?version=master&search= https://rust-lang.github.io/rustfmt/?version=master&search=
- ssokolow 6y ago
  Unfortunately, `rustfmt.toml` isn't expressive enough, even on nightly. I've had to make use of `rustfmt::skip` in various places to keep it from doing things like mangling the groupings and explanatory comments in `const` arrays or making code gratuitously tall and thin. ...and that sometimes means either `git gui` cherry-picking and only running rustfmt infrequently or applying `rustfmt::skip` too broadly because of errors like "error[E0658]: attributes on expressions are experimental" (I'm in the process of migrating from cherry-picking to over-broad `rustfmt::skip` so I can use format-on-save.)
jdashg 6y ago
It's a local maxima, but it prohibits maximally readable code. I just don't think it's a big win, but I've found it's a hard rhetorical battle to fight. Everyone's more cynically fearful of ugly code rather than having that extra leeway to write extremely readable code. I've definitely found this can throw the baby out with the bath water.
bananaface 6y ago
What's more important IMO is the erasure of time & mental overhead that are normally spent formatting. Formatting is (broadly) a giant waste of time. I honestly do not care if the result is ugly. And that ignores the synergistic benefits of erasing all style-based co-ordination problems & arguments & bikeshedding & whatever else from the entire codebase. IMO it's a no-brainer.
- zamalek 6y ago
  > erasing all style-based co-ordination problems & arguments & bikeshedding & whatever else from the entire codebase. Exactly this. I sat across from the poor soul who was assigned to creating the coding standards for our C# stuff. It tooks months. Nobody was happy, everyone had their own way of doing things: var vs. no-var vs. obvious-type-var, CONST_VALUE vs ConstValue. The work has been completed (the person in question quit soon after), people are still unhappy, there are still (and will always be) open questions. People nit coding standards in code reviews instead of looking for real issues. What a shitshow. If you remove autonomy concerning coding standards from the get-go, people never form these opinions. If code is not optimally pretty, that sucks. Establishing coding standards is an bottomless pit of despair. Almost any opinionated formatter is worlds better than the worthless sisyphian task of establishing your own coding standards.
rstuart4133 6y ago
> Even though it's a bit ugly, this is a big win. As someone observed above it's the only win you are likely to get, as ugly often boils down to "something I have seen before". There a few idioms that are actively helpful or harmful. For example, python making whitespace significant neatly meshes with human visual system. We are really good a picking up changes in indentation, not so good at lining up curly brackets. But best of luck trying to get 1/2 the population to accept that, even though it's objectively accurate. On the other side, allowing too many levels of operator precedence seems to be harmful. I loved the conciseness when I was young. It was only later I noticed people struggled with some of my code because of it. Pascal (I think?) solved the problem by making combining some operators without parenthesis a syntax error. But since I only used Pascal when I was young, I hated it whenever I did use it. So yeah, consistency is the only easy win. And as you say it's a big one: consistently formatted code is much easier to read than a miss-mash.

cgrealy 6y ago

Consistency > prettiness

berkut 6y ago
Is it just prettiness though? When I worked in the defence industry (~15 years ago now), a lot of the coding standards for C/C++ (which was starting to be used more and more over ADA at the time) were very strict on the matching alignment of things like open / closing braces, so things like hanging braces were not allowed, both opening and closing braces had to be on their own lines. The argument behind this was it made the code clearer, and more easy to match clauses / scoping - in a way arguing it was "safer" in terms of interpretation of the code.
- hurrrrrrrr 6y ago
  Maybe, maybe not. Is the potential benefit even worth fighting over? Style is just full of so many subjective details that every discussion ends in. And everybody has their favorite it's un-fucking-readable. My oppinion converged on "Fight it out and tell me what options in $formatter I need to set. Don't even tell me reasonings, just the options. leaves room". I'd rather drink coffee than have the next horizontal real estate vs. parameter alignment debate. The argument to match clauses/scoping for example is weird in a world where a formatter automatically applies indentation. It might make sense when you have to manually check them on print-outs without an Editor. I'd argue GNU style fulfills that role even better or Horstmann if you care about vertical real estate (or be daring and combine the two). And now everyone hates me.
  - berkes 6y ago
    I lean to the other side. In a way that I tell the requester "you better have some really, really good reason for wasting my time on this". Hell, I've even had a new hire prepare an entire presentation to convince us to change the line-length to something different than "The Language Standard". "We follow the language standard" and if you don't like it, convince upstream (This was Rubocop/Ruby) is another one I've used in the past. Naturally both people just gave up. There really is a better way to spend time than on tuning and tweaking a linter. Nearly all linters have some way to document and define very local exceptions for that case when some external__dependency_IsMxing_camel_case or whatever.
shmerl 6y ago
That depends on how ugly that consistency is.

ncmncm 6y ago

When I worked for Ian Taylor (one of the creators of Go) it was a firing offense to waste time lining up columns or parentheses. Petty arranging is a waste of valuable time, time stolen from your employer if you have one. Just a one-unit indent provides all the information you need to convey to the reader. Rust's formatter not making up artificial alignment columns is the best thing about it.

qchris 6y ago

Just in case anyone's not familiar with it, I figured it's worth pointing that rustfmt is also really customizable, using a `rustfmt.toml` file in the source directory. It might take a little time to get right, but it's not as if you're stuck with the default options, and a .toml file is pretty easy to play around with. [1] https://rust-lang.github.io/rustfmt/?version=master&search= https://rust-lang.github.io/rustfmt/?version=master&search=

ssokolow 6y ago
Unfortunately, `rustfmt.toml` isn't expressive enough, even on nightly. I've had to make use of `rustfmt::skip` in various places to keep it from doing things like mangling the groupings and explanatory comments in `const` arrays or making code gratuitously tall and thin. ...and that sometimes means either `git gui` cherry-picking and only running rustfmt infrequently or applying `rustfmt::skip` too broadly because of errors like "error[E0658]: attributes on expressions are experimental" (I'm in the process of migrating from cherry-picking to over-broad `rustfmt::skip` so I can use format-on-save.)

jdashg 6y ago

It's a local maxima, but it prohibits maximally readable code. I just don't think it's a big win, but I've found it's a hard rhetorical battle to fight. Everyone's more cynically fearful of ugly code rather than having that extra leeway to write extremely readable code. I've definitely found this can throw the baby out with the bath water.

bananaface 6y ago

What's more important IMO is the erasure of time & mental overhead that are normally spent formatting. Formatting is (broadly) a giant waste of time. I honestly do not care if the result is ugly. And that ignores the synergistic benefits of erasing all style-based co-ordination problems & arguments & bikeshedding & whatever else from the entire codebase. IMO it's a no-brainer.

zamalek 6y ago
> erasing all style-based co-ordination problems & arguments & bikeshedding & whatever else from the entire codebase. Exactly this. I sat across from the poor soul who was assigned to creating the coding standards for our C# stuff. It tooks months. Nobody was happy, everyone had their own way of doing things: var vs. no-var vs. obvious-type-var, CONST_VALUE vs ConstValue. The work has been completed (the person in question quit soon after), people are still unhappy, there are still (and will always be) open questions. People nit coding standards in code reviews instead of looking for real issues. What a shitshow. If you remove autonomy concerning coding standards from the get-go, people never form these opinions. If code is not optimally pretty, that sucks. Establishing coding standards is an bottomless pit of despair. Almost any opinionated formatter is worlds better than the worthless sisyphian task of establishing your own coding standards.

rstuart4133 6y ago

> Even though it's a bit ugly, this is a big win. As someone observed above it's the only win you are likely to get, as ugly often boils down to "something I have seen before". There a few idioms that are actively helpful or harmful. For example, python making whitespace significant neatly meshes with human visual system. We are really good a picking up changes in indentation, not so good at lining up curly brackets. But best of luck trying to get 1/2 the population to accept that, even though it's objectively accurate. On the other side, allowing too many levels of operator precedence seems to be harmful. I loved the conciseness when I was young. It was only later I noticed people struggled with some of my code because of it. Pascal (I think?) solved the problem by making combining some operators without parenthesis a syntax error. But since I only used Pascal when I was young, I hated it whenever I did use it. So yeah, consistency is the only easy win. And as you say it's a big one: consistently formatted code is much easier to read than a miss-mash.