Hacker News Reader

Comment by steveklabnik | Hacker News Reader

A lot of the stuff that interests me is how much this focuses on making things automatic. Use compiler plugins to automatically check your code, use rustfmt to automatically reformat your code, use highfive to automatically greet new contributors, use homu to automatically ensure good CI, use Travis to automatically upload docs, etc.

I like things that are automatic. That way, I don't forget about them.

View on HN

One of the things that's had the greatest impact on me is a comment D.J. Bernstein made about writing good software:

  For more than a decade I have been systematically identifying error-prone
  programming habits—by reviewing the literature, by analyzing other
  people’s mistakes, and by analyzing my own mistakes—and redesigning my
  programming environment to eliminate those habits.

http://www.aaronsw.com/weblog/001502

Given his track record with writing software largely without security defects, this seems like a promising avenue advancement.

I agree with this. Having things be automatic and unified is great. If there is a standard that Rust enforces regarding style or lints, then any crate published should be easily read by others interested in contributing.

It removes the overhead of having to consider what style the main author used or what lints are in place when compiling it.

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=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.

Note that rustfmt is still highly experimental, it didn't even compile on stable Rust until yesterday. I wouldn't actually use it quite yet, and I feel like its mention here in the blog post is mostly as future-proofing for when it is actually ready.

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?)

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.

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).

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.

munificent's article about dartfmt discusses this issue and how it scores both and chooses between them: http://journal.stuffwithstuff.com/2015/09/08/the-hardest-pro...

The (adapted) code from that article was used as a stress test for rustfmt in September: https://github.com/nrc/rustfmt/issues/296

Servo doesn't mandate that style. We use a mix of column-aligned and shifted styles. We tend to column align a lot, but we're okay with other ways of aligning as long as it doesn't exceed 120 characters.

> It's the presumption behind these kind of rigid code reformatters.

Rustfmt isn't rigid!

It's highly configurable, file a bug if you want this sort of formatting to be a part of the configuration. I've already filed an issue that asks for a less aggressive line-splitter https://github.com/nrc/rustfmt/issues/448

I have to agree. Adding tons of whitespace is generally going to make things harder to read.

Personally, I'm very much into Ratliff (or banner style) indentation and using two spaces for your indent. I know that 4 is the standard for a lot of people, but my feeling is that this is generally the result of people using VeryLongVariableNamesThatGoOnForever and blocks that go on for a many lines.

The more concise code becomes and the shorter your blocks get, I have found that it becomes much more annoying to have to skip your eye further. This gets especially silly if you have anything with deep nesting.

Ratliff style just makes it so so easy to tell where a block terminates though. I have basically no idea why it isn't wildly popular.

Probably because editors don't support it.

> I like things that are automatic. That way, I don't forget about them.

Yes! And that way I don't have to _trust anyone_ (including myself) to remember them.

I can't wait for the day where I can safely run clippy on stable and fail my tests when code is formatted incorrectly (according to rustfmt) :)

Clippy running on stable is quite far off. We've had discussions about stabilizing plugins, but it's not happening soon.

Instead, make clippy an optional feature, and compile with `cargo build --features=clippy` on your CI on nightly.

> make clippy an optional feature

Yeah, that's what I'm doing but that is also the reason why nightly is an allowed failure on Travis…

I have high hopes for compiler plugins after the current internal refactorings (HIR, MIR), though :)

HIR/MIR don't really help much, actually. A stable plugin interface would probably be completely different.

And clippy uses a _lot_ of internals, so even if a plugin interface stabilizes there's no guarantee clippy will.

My understanding was that HIR was supposed to _be_ a stable plugin interface.

Perhaps. There's still a long way to go though, since you need a stable AST builder or qquote mechanism, among other things.

And HIR isn't nearly enough for clippy to work on stable.

Reply on news.ycombinator.com