You're viewing a single thread.
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.
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.
And you never include the switch-case-block indentation levels.
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.
Honestly I don't mind the indentation since C isn't going to give us many ways to address this with as little code.
That said, with compilers that are good at inlining trivial functions, I really do appreciate the "it does what it says on the tin" approach to using functions on things like this. Even if they're only used once. Comments would help too.
The logic in these if statements is inscrutable on a cold read like this. To me, that's a maintenance risk; imagine seeing a snippet this size on a PR. Having functions that name what the hell is going on could only help.