And I rather like your last suggestion in the first post, chaining them all together on one line – much cleaner.

I hate having these giant pyramids in my code, and my solution is – at least to my eyes – much cleaner. That said, yours is cleaner still.

Avid – check out “short-circuiting”. You’ll find (at least in PHP, where I do the majority of my coding (and I should have made that explicit in the article)) that if do_chunk_a() returns with false, none of the other functions will be evaluated as the expression is already guaranteed to return false.

$success=true;
if ($success) { $success=A(); }
if ($success) { $success=B(); }
if ($success) { $success=C(); }

Or, because they’re being split up, I’d want to report to the user on these failures. So:

$success=true;
if ($success) { $success=A(); }
if ($success) { $success=B(); } else { errorA(); }
if ($success) { $success=C(); } else { errorB(); }
if (!$success) { errorC(); }

But I think a little nesting would be easier to read then that.

if (object->Initialized() && parameter->Initialized())
object->DoSomethingWith(parameter);

In C++ the Initialized functions would often be declared const, and not modify the objects they’re called on. Thus, they are conceptually replaced with a true or false, and nothing is hidden.

If each of the chunks has significant side effects, it’s misleading, to me, to write the code as if it’s just checking if something is true/false, which using the return value directly in a chained && appears to do. Better to put the significant actions on their own line, even if it requires some nested ifs or similar, so it’s obvious that several different significant tasks are being done. You can also then comment to explain each task separately.

Instead of the natural / obvious meaning of “if (test) then (task)”, you’ve got an unusual and unusual-looking abuse of a language feature.

If the code chunks are rather large, then splitting them off into their own functions is a good idea, and they can certainly return a bool to indicate success or failure. This can be used in a compact series of nested ifs that’s quite easy to follow as it all fits on one screen, and appropriate variable names are quite good at self-documentation:

bool success = do_chunk_a();
if (success) {
success = do_chunk_b();
if (success) {
success = do_chunk_c();
}
}

… which is the whole code block, and easy enough to follow since it’s all visible at once.

Or, if there’s no subsequent code in the current function, and you really just dislike the nesting, abort the function upon partial failure:

bool success = do_chunk_a();
if (!success)
return false;
success = do_chunk_b();
if (!success)
return false;
return do_chunk_c();

Or, if you can’t return upon partial failure, but want to do away with the nesting, use a simpler and more explicit way to chain the successes from each call:

bool success = do_chunk_a();
if (success)
success = do_chunk_b();
if (success)
success = do_chunk_c();

Or, if you really want to reduce your code, why not:

bool success = do_chunk_a() && do_chunk_b() && do_chunk_c();

This even avoids the user having to figure out the assignment of success to itself business.

Any of these alternatives are *much* easier to read than your suggestion, IMO.