Rustfmt: [unstable option] blank_lines_upper_bound

Created on 13 Feb 2019  路  6Comments  路  Source: rust-lang/rustfmt

Tracking issue for unstable option: blank_lines_upper_bound

unstable option

Most helpful comment

May I ask why the default is 1? That's basically the only thing where I disagree with the standard style. I'd love to avoid having a rustfmt.toml.

My reasoning: more space between items is a useful visual separator. Rust files tend to get fairly long and often contain many different kinds of items. Compare that to some other languages, where there is usually just one class per file, for example. So in Rust files I often have "blocks" of items that somehow belong together. Maybe it's something like:

struct A;

impl A {
}

impl Display for A {
}


struct B;

impl B {
}

impl Display for B {
}

I think it should be pretty clear that some items belong closer together than others (specifically: all the A things should be somehow separated from all B things). And this is just a small example. Often I have multiple "layers" of items. So I naturally want to have larger separation between items of different "blocks". I usually use up to three blank lines between items.

So I'd like to propose increasing the default value to 3 or even 5. I think rustfmt shouldn't really be getting in the way of the programmer in this case.

But maybe people have strong opinions against large separators. I tried searching for previous discussions about this, but I found nothing. So please let me know either way!

All 6 comments

May I ask why the default is 1? That's basically the only thing where I disagree with the standard style. I'd love to avoid having a rustfmt.toml.

My reasoning: more space between items is a useful visual separator. Rust files tend to get fairly long and often contain many different kinds of items. Compare that to some other languages, where there is usually just one class per file, for example. So in Rust files I often have "blocks" of items that somehow belong together. Maybe it's something like:

struct A;

impl A {
}

impl Display for A {
}


struct B;

impl B {
}

impl Display for B {
}

I think it should be pretty clear that some items belong closer together than others (specifically: all the A things should be somehow separated from all B things). And this is just a small example. Often I have multiple "layers" of items. So I naturally want to have larger separation between items of different "blocks". I usually use up to three blank lines between items.

So I'd like to propose increasing the default value to 3 or even 5. I think rustfmt shouldn't really be getting in the way of the programmer in this case.

But maybe people have strong opinions against large separators. I tried searching for previous discussions about this, but I found nothing. So please let me know either way!

I would also like to voice my support for stabilizing this option. I personally use single lines between "paragraphs" in blocks of code, two lines between related functions and structs, and three lines between unrelated sections of source. This feature requiring nightly is rather frustrating

why is it nightly? I think it makes sense to be able to set it to 2

The discussion here seems like we will not change the default, unfortunately. So we could go ahead and stabilize this option. Only these conditions left:

  • The design and implementation of the option are sound and clean.
  • The option is well tested, both in unit tests and, optimally, in real usage.
  • There is no open bug about the option that prevents its use.

May I ask why the default is 1?

I also don't understand why the default is set to 1.

This gives no extra visual separation on different declarations, I would love to separate structs and enums, because I don't want my code to be compact, I want the structure to give hints about what the text means, this is is also the reason why we opt to add one blank line inside of functions, but everything with one line is confusing.

The discussion here seems like we will not change the default, unfortunately. So we could go ahead and stabilize this option. Only these conditions left:

  • The design and implementation of the option are sound and clean.
  • The option is well tested, both in unit tests and, optimally, in real usage.
  • There is no open bug about the option that prevents its use.

Where does this leave us now? Doesn't look like there are bugs open about the option other than this.

The other two points seem a bit subjective; a rust n00b like me certainly can't weigh in there, but I agree with the others that having this option in stable would be very nice.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Jerald picture Jerald  路  4Comments

LPGhatguy picture LPGhatguy  路  3Comments

thomaseizinger picture thomaseizinger  路  3Comments

ozkriff picture ozkriff  路  4Comments

gnzlbg picture gnzlbg  路  3Comments