here you go, linux 0.01

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?

You must be a sith...

Perhaps *(p += 1) will be to your liking?

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) {

Like with everything, context matters. Sometimes it can indicate poorly structured control flow, other times inefficient loop nesting. But many times it is just somebody’s preference for guard clauses. As long as the intent is clear, there are no efficiency problems, and it is possible to reach the fewest branches necessary, I see no issues.

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.

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

If your build fails because you can't track down the literal ≠ in the code I would recommend just looking at the compiler error. I understand the concerns about == vs = more but the vast majority of LSPs (and some compilers) will catch that too.

I have also yet to see any IDE enable ligatures by default, at least VS Code and the JetBrains suite both require opting into them even though their default fonts support them.

Then perhaps the code you are trying to extract doesn't make a clear and cohesive procedure. Maybe include more or less of the code, or rework the code into logical pieces or steps. Write the algorithm in human language first, then implement the steps using functions.

🤷‍♂️ Or fnck it.

That example looks like the PowerShell equivalent of piping complex things around 20 times before actually doing something with the results.

no but bro, the code complexity tool says that this scope has 14 complexity instead of 13, we gotta cram it in a single ternary for code legibility

In a one-liner competition, sure.

In my codebase? I'd pull a "let's linger after standup about your PR" and have the coder sweat through a 10 minute soapbox about nothing before laying down the law.