Sadly, that's not code Linus wrote. Nor one he merged. (It's from git, copied from rsync, committed by Junio)
here you go, linux 0.01
Isn't that from 1991 while the quote is from 1995? If we're nitpicking maybe we shouldn't time travel 🤓
Damn it Time Patrol! You can't stop me!
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...
I've heard similar from the worst first year CS students you could ever meet. People talk out their ass without the experience to back up their observations constantly. The indentation thing is a reasonable heuristic that states you are adding too much complexity at specific points in your code that suggests you should isolate core pieces of logic into discrete functions. And while that's broadly reasonable, this often has the downside of you producing code that has a lot of very small, very specific functions that are only ever invoked by other very small, very specific functions. It doesn't make your code easier to read or understand and it arguably leads to scenarios in which your code becomes very disorganized and needlessly opaque purely because you didn't want additional indentation in order to meet some kind of arbitrary formatting guideline you set for yourself. This is something that happens in any language but some languages are more susceptible to it than others. PEP8's line length limit is treated like biblical edict by your more insufferable python developers.
line 152 is the only thing past 3 levels and I'd say that one gets a pass.
You really think someone would do that? Just go on the internet and tell lies?
Plus it shows three levels of indentation. Well... there is the extra one created by the compiler directives, but do they really count?
rules aren't there to be enforced, they're there so that when you break them you take a second to think about why.
I didn't know why, but *++p bugs me
Perhaps *(p += 1) will be to your liking?
Much better... but can we make it *((void*)(p = p + 1))?
How about some JavaScript p+=[]**[]?
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?
In C an assignment is an expression where the value is the new value of what was being assigned to.
In a = b = 1, both a and b will be 1.
a = *(p = p + 1)
is the same as
p += 1
a = *p
, so ++p.
welcome to C
That *++ operator from C is indeed confusing.
Reminds me of the goes-to operator: --> that you can use as:
while(i --> 0) {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.
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.
I think it's a lineature. FiraCide does that for example, and I like it very much. My compiler and lsp will tell me if there is a bad char there. Besides, the linea tires take the same space as two regular characters, so you can tell the difference.
It's not the 90s anymore. My editor can look nice.
In a world where your IDE and maybe also compiler should warn you about using unicode literals in source code, that's not much of a concern.
VSCode (and I'm sure other modern IDEs, but haven't tested) will call out if you're using a Unicode char that could be confused with a source code symbol (e.g. i and ℹ️, which renders in some fonts as a styled lowercase i without color). I'm sure it does the same on the long equals sign.
Any compiler will complain (usually these days with a decent error message) if someone somehow accidentally inserts an invalid Unicode character instead of typing ==.
Why is multiple levels of indentation bad?
IDK, but if the reason is "to break stuff into multiple functions", then I'm not necessarily writing yet another single-use function just to avoid writing a comment, especially in time critical applications. Did that with a text parser that could get text formatting from a specifically written XML file, but mainly due to it being way less time critical, and had a lot of reused code via templates.
It's important to remember that Linus is primarily writing about C code formatting. C doesn't have things that tend to create more deeply nested structures, such as a formal class syntax, or nested functions.
Going too deep is still bad--as zea notes, it's an indication of control structures run amok--but the exact number is dependent on the language and the context.
Indentation implies there's some control structure causing it. Too many control structures nested gets hard to mentally keep track of. 3 is arbitrary, but in general more indentation => harder to understand, which is bad.
While I totally agree with that philosophy, it heavily depends on the language.
For Rust, my philosophy is more like this:
Broad generalizations aren't for the people who make them, they're for the suckers who consistently fall for them
The number one thing that gets in my way of refactoring to function is figuring out what to name the functions takes too long.
Ligatures 🤢🤮🤮
What's wrong with Ligatures? It makes reading code a bit more tolerable.
I mean, I certainly wouldn't give someone else shit for using ligatures, but personally, I don't like them, because:
You're brave (I don't agree)
My personal code readability axe to grind is nested complex ternary operators.
Every now and then I'll see something like this
return (checkFormatType(currentObject.type==TYPES.static||currentObject type==TYPES.dynamic?TYPES.mutable:TYPES.immutable)?create format("MUTABLE"):getFormat(currentObject));
And I have a fucking conniption because just move that shit into a variable before the return. I get it when sometimes you just need to resolve something inline, but a huge amount of the time that ternary can be extracted to a variable before the ternary, or just rewrite the function to take multiple types and resolve it in the function.
This posts entire comment chain is an interesting example of people that have extensive knowledge in completely different areas of programming to me. And have some concepts I had never heard/thought of.
You get one level at the get go because everything is in a function. So just two levels of indentation? A pretty basic if.. for..if nesting has to be refactored? Into what? Goto? Should I sprinkle return statements all over the place?
Y’all gotta understand that Linus is often kind of an ass.
Uses multiple returns... I'm switching to Windows.
You mean you are early-returning to windows, uh? You can't do that by your own rules.
Fuck.
What's wrong with multiple returns?
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.
If your function is so long that keeping track of returns becomes burdensome, the function is too long.
I'm not a fan of returning status codes, but that's a pretty clear example of early return validation where you can't just replace it with a single condition check. Having a return value that you set in various places and then return at the end is worse than early return.
Post funny things about programming here! (Or just rant about your favourite programming language.)