got him

Isn't that from 1991 while the quote is from 1995? If we're nitpicking maybe we shouldn't time travel 🤓

I mean it was 0.01, at that point he was screwed anyway, and he fixed his program.

He wouldn't make that statement unless he experienced the horror himself.

Now, if he still does it these days...

line 152 is the only thing past 3 levels and I'd say that one gets a pass.

Absolutely.

They might be a sith.

Much better... but can we make it *((void*)(p = p + 1))?

p = 1

x = ++p
// x = 2
// p = 2

p = 1
x  = p++
// x = 1
// p = 2

++p will increase the value and return the new value

p++ will increase the value and return the old value

I think p = p + 1 is the same as p++ and not as ++p. No?

That's not a real operator. You've put a space in "i--" and removed the space in "-- >". The statement is "while i-- is greater than zero". Inventing an unnecessary "goes to" operator just confuses beginners and adds something else to think about while debugging.

And yes I have seen beginners try to use <-- and --<. Just stop it.

And you never include the switch-case-block indentation levels.

Ligature, not lineature.

are there ligatures for monospace fonts that don't preserve the width of the characters?

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.

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

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?

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

Yeah, the annoying thing is the people who I generally have found to be the worst about stuff like this are old school Senior C developers, who still program like it's 1987 and we have to fit everything into 4K of RAM.

Fortunately there's nothing like that in my code base, I just run into stuff like that periodically when I'm digging around in other team's server code looking for something.

Sometimea the smallest logical unit of an algorithm uses more than 3 levels of indentation

Fuck.

Maintainability.

You can't read a block of code and as quickly and understand its control flow without reading every line, especially in regards to resource cleanup.

For example say you have:

...
if this:
    something
    or other
    and many more...
    ...
else:
    yet another thing 
    and some more
    ...

do some cleanup
return
...

Say you aren't exactly interested in what happens inside each branch. If you can assume that there's one return at the end of the block, you can see the if and else, you can reason about what values would trigger each branch, you can also see that no matter which branch is executed, the cleanup step will be executed before returning. Straightforward. I don't have to read all the lines of the branches to ensure the cleanup will be executed. If I can't assume a single return, I have to read all those lines too to ensure none of them jumps out of the function skipping the cleanup. Not having to think about such cases reduces the amount of reading needed and it makes reasoning about the block simpler. The bigger the blocks, the more the branches, the stronger the effect. You have one less foot-shotgun to think about. The easier you make it for your brain, the fewer mistakes it's gonna make. For all those days when you haven't slept enough.

E: Oh also refactoring blocks of code out into functions is trivial when you don't have multiple returns. Extracting a block with a return in it breaks the parent control flow and requires changes in the implementation.

E2: Shorter blocks do not obviate this argument. They just make things less bad. But they make almost everything less bad. Shorter blocks and single returns make things even better.

I mean, I certainly wouldn't give someone else shit for using ligatures, but personally, I don't like them, because:

• they break with monospacedness. Everything is in a nice grid and you've randomly got these character combinations that needlessly stick out.
• they sometimes happen in places where they really shouldn't.
• they hide what the actual characters are. Especially, if go to edit that code, my brain will really struggle for a split-second when there's a '≠', then I delete one character and rather than the whole thing disappearing, I'm left with a '!'.