While I totally agree with that philosophy, it heavily depends on the language.
For Rust, my philosophy is more like this:
- Impl + fn body don’t count, as well as async blocks if they span the whole function
- do not nest more than one if statement. You probably better using guard clauses or matches
- do not put loops into an if statement.
- do not nest loops unless clearly shown to be (X, Y) indexing
- method chaining is free
- do not nest closures, unless the nested closure doesn’t have a {} block
- do not use mod unless it’s test for the current module. No I don’t want to Star Wars scroll your 1000 line file. Split it.
Why have an async block spanning the whole function when you can mark the function as async? That’s 1 less level of indentation. Also, this quite is unusable for rust. A single match statement inside a function inside an impl is already 4 levels of indentation.
A single match statement inside a function inside an impl is already 4 levels of indentation.
How about this?
The preferred way to ease multiple indentation levels in a
switch
statement is to align theswitch
and its subordinatecase
labels in the same column instead of double-indenting the case labels. E.g.:
switch (suffix) {
case 'G':
case 'g':
mem <<= 30;
break;
case 'M':
case 'm':
mem <<= 20;
break;
case 'K':
case 'k':
mem <<= 10;
/* fall through */
default:
break;
}
I had some luck applying this to match
statements. My example:
let x = 5;
match x {
5 => foo(),
3 => bar(),
1 => match baz(x) {
Ok(_) => foo2(),
Err(e) => match maybe(e) {
Ok(_) => bar2(),
_ => panic!(),
}
}
_ => panic!(),
}
Is this acceptable, at least compared to the original switch
statement idea?
Well, of course you can have few indent levels by just not indenting, I don’t think the readability loss is worth it though. If I had give up some indentation, I’d probably not indent the impl {} blocks.
It’s a lot less readable imo. As well than a cargo fmt
later and it’s gone (unless there’s a nightly setting for it)
i personally find this a lot less readable than the switch
example. the case
keywords at the start of the line quickly signify its meaning, unlike with =>
after the pattern. though i dont speak for everybody.