4 ms·

rustfmt makes me sad. So do the official Rust and Servo style guides. The whitespace style they mandate ("column align all the things!") is wildly impractical.

rustfmt makes me sad. So do the official Rust and Servo style guides. The whitespace style they mandate ("column align all the things!") is wildly impractical. I used to use this exact same style myself, many years ago, but gave it up when I saw how many problems it caused. I'll never go back to this kind of column-aligned formatting. Here's an example from the rustfmt source code: let mut rewrites = try_opt!(subexpr_list.iter() .rev() .map(|e| { rewrite_chain_expr(e, total_span, context, max_width, indent) }) .collect::<Option<Vec<_>>>()); Here's how I would format that code instead: let mut rewrites = try_opt!( subexpr_list .iter() .rev() .map( |e| { rewrite_chain_expr( e, total_span, context, max_width, indent ) }) .collect::<Option<Vec<_>>>() ); Or, perhaps if the variable names in the rewrite_chain_expr() call were a little longer, like this: let mut rewrites = try_opt!( subexpr_list .iter() .rev() .map( |e| { rewrite_chain_expr( e, total_span, context, max_width, indent ) }) .collect::<Option<Vec<_>>>() ); Either way, the difference is that I use indentation everywhere that the rustfmt style uses column alignment. This kind of indentation-based style has numerous advantages over a column-aligned style. I wrote about this at some length previously, so rather than repeat the details, here are my previous comments for anyone who is curious about the rationale for this indentation style: https://news.ycombinator.com/item?id=10206860 https://news.ycombinator.com/item?id=10206860 https://news.ycombinator.com/item?id=9469713 https://news.ycombinator.com/item?id=9469713 Anyway, it isn't the rustfmt style itself that makes me sad. It's the presumption behind these kind of rigid code reformatters. The bottom line seems to be this collection of notions: 1. Consistent code formatting and whitespace style is vitally important. So important that an automated tool is required to insure that there are no variations in formatting. 2. The exact details of how code is formatted don't matter much. Any formatting style is about as good as any other, as long it is 100% consistent within a project (or language, or whatever). A professional programmer should just find out what the standard is and follow it. 3. There is nothing new to be learned in formatting style. The way we've always done it is good enough, and as good as any other. (See #2.) If you have new and different ideas about whitespace, they are unhelpful and unwelcome. Stop bikeshedding! And that is what makes me sad.

steveklabnik 11y ago
The exact style hasn't been settled yet. We'll be going through RFCs, as usual, for at least the major points. Rustfmt is a start to this, not the final word. (I would also format like #2, personally. I think Rustfmt might even have a setting to do it this way?)
- Stratoscope 11y ago
  Oh! In that case I have probably misjudged Rustfmt. My apologies. I was also overdramatizing with the "makes me sad" bit. :-) I'm not an active Rust user, so probably won't be involved in the RFC process, but I'm glad to hear about it. OTOH, even for a language I do actively use, I'm a bit reluctant to get involved in a formatting standards process. So many people seem to approach code formatting from a point of view of "This is how we've always done it, this is consistent with other previous standards, so this is how it should be." And then whoever gets the most agreement wins. I don't often see discussions based on whether there may be actual engineering advantages to one formatting style vs. another. For example, I put spaces inside the parentheses in my function calls and expressions. Many see that as an arbitrary stylistic choice - and object vehemently to it! - but it actually ties in very closely to the column alignment vs. indentation choice in the examples above. I talked about that in some detail in one of the comments I linked above, so won't belabor it further here. :-) Maybe that's my beef with coding standards: they tend to take each style decision as an independent, fairly arbitrary choice, instead of listing the goals we're looking for and seeing how different style choices may work together to achieve them.
  - Manishearth 11y ago
    The idea is to pick a standard that people can use as a default, which becomes the "familiar Rust standard". It's mostly for folks who _don't_ care much about formatting nuances. If you do have a style you prefer, you can always configure your rustfmt to follow that style.
  - tatterdemalion 11y ago
    I don't think there's very much empirical evidence about the engineering advantages of different code style standards. Fortunately, Rust's approach will always be to establish a reasonable compromise and allow you to deviate for your projects (this is why rustfmt is designed to be configurable).

steveklabnik 11y ago

The exact style hasn't been settled yet. We'll be going through RFCs, as usual, for at least the major points. Rustfmt is a start to this, not the final word. (I would also format like #2, personally. I think Rustfmt might even have a setting to do it this way?)

Stratoscope 11y ago
Oh! In that case I have probably misjudged Rustfmt. My apologies. I was also overdramatizing with the "makes me sad" bit. :-) I'm not an active Rust user, so probably won't be involved in the RFC process, but I'm glad to hear about it. OTOH, even for a language I do actively use, I'm a bit reluctant to get involved in a formatting standards process. So many people seem to approach code formatting from a point of view of "This is how we've always done it, this is consistent with other previous standards, so this is how it should be." And then whoever gets the most agreement wins. I don't often see discussions based on whether there may be actual engineering advantages to one formatting style vs. another. For example, I put spaces inside the parentheses in my function calls and expressions. Many see that as an arbitrary stylistic choice - and object vehemently to it! - but it actually ties in very closely to the column alignment vs. indentation choice in the examples above. I talked about that in some detail in one of the comments I linked above, so won't belabor it further here. :-) Maybe that's my beef with coding standards: they tend to take each style decision as an independent, fairly arbitrary choice, instead of listing the goals we're looking for and seeing how different style choices may work together to achieve them.
- Manishearth 11y ago
  The idea is to pick a standard that people can use as a default, which becomes the "familiar Rust standard". It's mostly for folks who _don't_ care much about formatting nuances. If you do have a style you prefer, you can always configure your rustfmt to follow that style.
- tatterdemalion 11y ago
  I don't think there's very much empirical evidence about the engineering advantages of different code style standards. Fortunately, Rust's approach will always be to establish a reasonable compromise and allow you to deviate for your projects (this is why rustfmt is designed to be configurable).