rules aren’t there to be enforced, they’re there so that when you break them you take a second to think about why.
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
switchstatement is to align theswitchand its subordinatecaselabels 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
matchstatements. 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
switchstatement idea?i personally find this a lot less readable than the
switchexample. thecasekeywords at the start of the line quickly signify its meaning, unlike with=>after the pattern. though i dont speak for everybody.How about this one? it more closely mirrors the switch example:
match suffix { 'G' | 'g' => mem -= 30, 'M' | 'm' => mem -= 20, 'K' | 'k' => mem -= 10, _ => {}, }How about this other one? it goes as far as cloning the switch example’s indentation:
match suffix { 'G' | 'g' => { mem -= 30; } 'M' | 'm' => { mem -= 20; } 'K' | 'k' => { mem -= 10; } _ => {}, }
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.
I just got some idea yesterday regarding
implblocks, ready to be my respondent?I had a big
implblock with 4 levels of indentation, so I cut the block, and replacedimpl InputList { //snip }with
mod impl_inputlist;and moved theimplblock to a new file, and did not indent anything inside that block.The advantage this has over just not indenting the
implblock in place, is that people will have difficulty distinguishing between what’s in the block and what’s outside, and that’s why theimplwas moved to its own exclusive file, impl_inputlist.rsMaybe I am overstressing indentation. Ss there something wrong with my setup that prevents me from accepting 4-space indentation?
I use:
Editor: Neovide
Font: “FiraCode Nerd Font Mono:h16” (16px fonts are addicintg)
Monitor: 1366x768, 18.5 inch, 10+ years old, frankenstein-ly repaired Samsung monitor.
Distance: I sit at about 40-60 Cm from my monitor.
That leaves me with a 32x99 view of code excluding line numbers and such.
It’s a lot less readable imo. As well than a
cargo fmtlater and it’s gone (unless there’s a nightly setting for it)Formatters are off-topic for this, styles come first, formatters are developed later.
My other reply:
How about this one? it more closely mirrors the switch example:
match suffix { 'G' | 'g' => mem -= 30, 'M' | 'm' => mem -= 20, 'K' | 'k' => mem -= 10, _ => {}, }How about this other one? it goes as far as cloning the switch example’s indentation:
match suffix { 'G' | 'g' => { mem -= 30; } 'M' | 'm' => { mem -= 20; } 'K' | 'k' => { mem -= 10; } _ => {}, }
One nit: whatever IDE is displaying single-character surrogates for
==and!=needs to stop. In a world where one could literally type those Unicode symbols in, and break a build, I think everyone is better off seeing the actual syntax.
