tags:

views:

497

answers:

11

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

+6  A: 

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.

Sebastian Dietz
I thought about that, but couldn't premature extraction of code used only in one place be placed up there with premature optimization? Unless the code is reused, I wouldn't extract it, but just make sure each code block was commented appropriately.
Thomas Owens
Premature optimization is bad because it's often a waste of time. Extracting code is not a waste of time if it makes it easier to understand (and thus maintain) the program.
drby
@Thomas Owens: As hackingwords says, if the code is hard to read by being nested too deeply, I don't see it as premature optimization, but as increasing the maintainability. Adding comments just adds redundant information that can be conveyed by function names in a better way.
Sebastian Dietz
A: 

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.

chills42
+2  A: 

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.

Denis Hennessy
A: 

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.

Tim Post
A: 

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

Eduard - Gabriel Munteanu
+4  A: 

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.

ng5000
A: 

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.

Gilad Naor
A: 

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.

Kristopher Johnson
A: 

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.

James Dean
Doesn't this refer more to coding style? Because taller screens, no whitespace, or in-line bracing would allow more screen landscape and would imply that the code is less complex than the same code that was spaced out more.
put all the code on one nested if, and you'd get 28 levels of indent by that measure (my editor shows 58 lines on screen). I rarely use more than 4 indents, including the one for the method body.
Pete Kirkham
A: 

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.

For most complexity rules I've seen, there are exceptions in terms of Big Dumb Functions, which may have large numbers of decision points or nesting, but are still easy to understand.
David Thornley
A: 

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.

Kristo