this post was submitted on 09 May 2024
458 points (92.4% liked)

Programmer Humor

32718 readers
446 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS
[email protected]
[email protected]
458
got him (lemy.lol)
submitted 7 months ago by [email protected] to c/[email protected]
134 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 25 points 7 months ago* (last edited 7 months ago) (4 children)

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.
[–] [email protected] 5 points 7 months ago (2 children)

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.

[–] [email protected] 4 points 7 months ago

Those async blocks exist when doing async in traits.

And I never said I respected the 4 level of indentations. That's exactly the point of those rules. Keep it lowly indented but still readable

[–] [email protected] 1 points 7 months ago (3 children)

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 the switch and its subordinate case 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?

[–] [email protected] 3 points 7 months ago (1 children)

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)

[–] [email protected] 0 points 7 months ago (1 children)

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;
       }
_ => {},
}
[–] [email protected] 4 points 7 months ago

I mean, I use formatters everywhere I can exactly so I don’t have to think about code style. I’ll take a full code base that’s consistent in a style I dislike, over having another subjective debate about which style is prettier or easier to read, any day. So whatever cargo fmt spits out is exactly what I’ll prefer, regardless of what it looks like, if only for mere consistency.

[–] [email protected] 2 points 7 months ago (1 children)

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.

[–] [email protected] 0 points 7 months ago* (last edited 7 months ago)

I just got some idea yesterday regarding impl blocks, ready to be my respondent?

I had a big impl block with 4 levels of indentation, so I cut the block, and replaced

impl InputList {
    //snip
}

with mod impl_inputlist; and moved the impl block to a new file, and did not indent anything inside that block.

The advantage this has over just not indenting the impl block in place, is that people will have difficulty distinguishing between what's in the block and what's outside, and that's why the impl was moved to its own exclusive file, impl_inputlist.rs

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

[–] [email protected] 2 points 7 months ago (1 children)

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.

[–] [email protected] 0 points 7 months ago* (last edited 7 months ago) (1 children)

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;
        }
_ => {},
}
[–] [email protected] 2 points 7 months ago

the problem is that, while skimming the start of each lines, nothing about 'G' | 'g' tells me that its a branch. i need to spend more time parsing it. mind you, this may simply be a problem with rust's syntax, not just ur formatting.

[–] [email protected] 5 points 7 months ago (1 children)

I don't know enough Rust to understand by what you mean by the last one. My understanding was that mod name was just declaring the module that this file depends on. Could you explain what I should do instead? Since your other statements I totally agree with, I should probably agree with the last one.

[–] [email protected] 8 points 7 months ago (1 children)

mod name declares that the module should be compiled and reachable as a submodule of the current module. This assumes that you have a file or directory of the name in the right place. This is what you should do.

You can also declare a module like this: mod name {...} where you just put the content in the block. The two are functionally equivalent, from the compilers perspective.

[–] [email protected] 1 points 7 months ago (1 children)

I don't understand how to follow this bullet point that I was replying to.

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.

I already know what mod does in a basic sense, I wanted to know what the commenter meant by this.

[–] [email protected] 1 points 7 months ago* (last edited 7 months ago) (1 children)

This point advocates against the use of mod with content in a file unless it is used for a testing module. A common pattern is to have the unit tests for a module inside the main module file. Tests in rust are just specially tagged functions. To avoid compilation costs in non-test builds and false unused code warnings you can put all test related code in a submodule and tag that module with #[cfg(test)]. That way the module will only be included and compiled if the crate is being compiled to run tests.

The Star wars thing refers to scrolling long text files similar to the intro of the starwars movies where a long text is scrolled for the viewer.

[–] [email protected] 1 points 7 months ago

Oh so its just referring to writing the mod's code in the same file the mod is declared in being bad form? That seems very reasonable; since the point of a module is code separation so it makes sense to always put it in its own file. Good, I'm already doing that at least!

[–] [email protected] 4 points 7 months ago (1 children)

what if I need to nest if lets

[–] [email protected] 4 points 7 months ago (1 children)

Use a match? Unless it's for guard clauses, a match is fine enough

[–] [email protected] 1 points 7 months ago (1 children)

what if i need to if let on the result of another if let

[–] [email protected] 1 points 7 months ago (1 children)

Oh, then you use and_then() or something similar.

There's also the possibility to use the guard clauses patern and do let <...> = <...> else {}.

And finally, you can always split into another function.

It's not straight rules. It depends on what makes it more readable for your case.

[–] [email protected] 1 points 7 months ago

what about if on a boolean followed by an if let

[–] [email protected] 0 points 7 months ago

I'ma gonna steal this.