got him

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

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

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

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.

It's very likely plain old C

They might be a sith.

Ligature, not lineature.

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?

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.

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

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 '!'.

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.