Levels of Indentation - c++

Question

How many levels of indentation do you consider reasonable?
I feel that having a C++ function with 4/5+ levels of indentation is normally a bad thing. It implies that you have to mentally keep track of 4/5+ things the whole time.
Is my opinion justified?
(yes, I can avoid having multiple levels of indentation by not indenting at all:)

Answer 1

I agree with you. If a function has more than 4 or 5 nested if/switch/loop/try statements, parts of it should be extracted into their own functions.
This will make the code more readable because the extracted functions' names are usually more descriptive than the code itself.

Answer 2

It depends entirely on the problem you code is trying to solve. Sometimes you have no choice but to have quite deep levels of indentation, though it certainly is a code smell.
I think you're right in that 4 or 5 levels or so is reasonable, more and you should probably be looking to refactor the method.
It's also worth noting that people have been trying to quantify code quality and design metrics for many years. One of the more common metrics is cyclomatic complexity.

Answer 3

Actually, it's not the number of indentation levels that most contributes to unreadable code, it's the length of the module/function/method that you're looking at.
Of course, long sections typically have more levels of indentation because blocks of code are used inline rather than broken out so there is a relation between. Personally, I think there's a smell if a method has more than a couple of screenfuls of code and more than 6 levels of indentation.

Answer 4

I think it can depend on the situation, but generally you'll want less nesting.
Nested loops can kill performance, and nested if statements can ofter be reduced down to less levels.
The problem is that often you run into issues trying to optimize too early in your development. I think that you should always take a little time to consider the possibilities before doing 3+ levels of nesting.

Answer 5

My only pet peeve regarding indentation is when two keywords are used and one depends on the other. For instance:
switch (c) {
case 'x':
foo = bar;
That is bad, you can't have a case outside of a switch, so:
switch (c) {
case 'x':
foo = bar;
.. would be much better. Indentation tends to get crazy in switches with if / else if / else. I also highly recommend keeping an 80 (at most 110 column limit) while indenting. Nobody likes scrolling 30 columns to the right to see what your doing, and 30 columns back to see how you handle the results :) Never mind that poor soul that has to edit your code in dumb 80x25 console mode on a server.

Answer 6

Although what I'm going to say comes from a plain C standpoint, it might apply to C++ as well. I favor the Linux kernel coding style, that is: 8 characters-wide tab indentation (natural tab) and as many levels of indentation as there fit on a 80x25 terminal (without exceeding the 80 characters width, that is).

Answer 7

Too much indentation is probably a sign that you should refactor: create a couple more small methods with good names. That way you break up the logic into smaller pieces that are easier to gobble up.

Answer 8

This relates to the question of how long a function should be. If you keep your function bodies to ten lines or fewer, then it's really hard to get too many levels of indentation.
I think 4 or 5 levels is too many. You can almost certainly factor out some of those inner loops or conditionals into their own functions.
I feel queasy with three levels of indentation myself. Even two levels causes me to reconsider what I'm doing.

Answer 9

Many levels of indentation is fine as long as you can see the all the open and close brackets at the same time in your editor.
This tends to limit you to maybe 4 levels max in practice.

Answer 10

One thing to note however is that some nesting levels are necessary and should not be abstracted out.
If you have some sort of brute force iteration over a 4D array, then you've got four levels of nesting automatically, and if there's is an IF statement, then you have five levels without having a particularly convoluted section of code.
So the level of nesting isn't necessarily the problem, it's the complexity attached to each level of nesting. If you are mixing WHILEs, FOREACHs, IFs and SWITCHes then maybe you should boil them down.
The basic point is that levels of nesting aren't always an indicator of complexity.

Answer 11

IIRC, Linus Torvalds would agree with you. I believe he insists on an 8-space indent and a 80-character line length for the linux kernel code. When you get to 4 or 5 levels of indent under that scheme your code would look scrunched horribly. You're forced to try to refactor the code just to maintain readability.

Answer 12

I used to think Linus was a bit of a hard-ass on this when he said no more than 3 levels or else your code is broken, i.e., but following that principle has helped me a lot in reasoning about my control flows. That said, I had to interpret it differently. The intuitive interpretation is that you should create more and more itsy bitsy functions. I don't recommend taking that idea to the extreme as that can make your control flows and side effects just as difficult to reason about when all the side effects are obscured by function calls leading you all over the place.
What helped me enormously was favoring deferred processing and simpler loops. Take this as an example:
// Remove vertices from mesh.
for each vertex in vertices.to_remove:
{
for each edge in vertex.edges:
{
for each face in edge.faces:
{
face.remove_edge(edge);
if (face.size() < 3)
face.remove();
}
edge.remove();
}
vertex.remove();
}
That monstrous thing with 4 levels of indentation above is awkward (and more so when it's not in pseudocode form where it might have to update texture maps and so on requiring even more levels of indentation). We can instead do this:
for each vertex in vertices.to_remove:
{
for each edge in vertex.edges:
edges_to_remove.insert(edge);
}
for each edge in edges_to_remove:
{
for each face in edge.faces:
faces_to_rebuild.insert(face, edge);
}
for each face,edge in faces_to_rebuild:
{
face.remove_edge(edge);
if (face.size() < 3)
face.remove();
}
for each edge in edges_to_remove:
edge.remove();
for each vertex in vertices_to_remove:
vertex.remove();
While that involves more passes over the data and some additional state, it makes every loop much simpler. And when we have these simpler loops, they become easier to parallelize, and the memory access patterns can start taking on a cache-friendly nature with decent data structures in place.
I've found that favoring this type of deferred processing not only reduces those indentations but also simplifies my ability to comprehend what the code is doing since the control flows are dead simple and they're all causing only one type of uniform side effect. It makes it so much easier to see what each loop is doing and comprehend whether it is doing the right thing or not at a glance, since each one is dedicated to causing one type of side effect, not many different types of side effects. And surprisingly, in spite of the extra work, it often improves cache coherence, and also opens up new doors for multithreading and SIMD, and I end up getting an even more efficient result than I started.