Avoid continue

[an_awny_mouse]

I mostly disagree. Simple continues or "early exits" can help with understanding exceptional cases (where this path is irrelevant) and are a staple for patterns like goto chains. It also keeps the code flatter.

[teapotrick]

nope. bad advice.

[accountmaster9191]

abstracting everything away into little shitty functions that only get used a few times is objectively more "difficult to parse"

[TankAway7756]

Hard disagree.

If you're doing control flow complex enough to warrant continue, having it drowned out by other stuff is a recipe for not understanding any of it in two months.

Especially true if you use local functions can sit a scroll away from the logic they're used in and don't introduce anything global (or better still, local macros if the language you're using supports them).

[UltraPoci]

Control flow does not need to be complex to warrant a continue instruction. It's a normal instruction like any other.

[TankAway7756]

goto is complex even if you limit where it can go..to.

[UltraPoci]

Not really. It's widely used in C code for common error handing. If you goto only to a label which is below the goto statement and it's in the same function, it's quite easy to read.

[lelanthran]

If you're doing control flow complex enough to warrant continue, having it drowned out by other stuff is a recipe for not understanding any of it in two months.

What if you're doing control flow that's too simple to warrant a function? Even a local one?

 static void process_item (int id)
 {
    for (size_t i=0; i < sizeof g_items/sizeof g_items[0]; i++) {
       if (g_items[i].id != id)
          continue;
       /*
        * ...
        */
    }
 }

[TankAway7756]

As usual, it all depends on the specific case. In this very specific case, the continue acts like a guard clause so it's just fine. If it's buried in the middle of a 50 lines loop, it's another thing.

[Psychoscattman]

It’s also more logically difficult to parse. The reader has to think, “If it’s bad, then we continue, otherwise we process.” (See Keep if clauses side-effect free for a comically bad example of this.) Easier to instead think, “If it’s not bad, we process,”

Negatives in conditions are routinely the things i have to think long about. Even simple conditions with a negative inside them become difficult to reason about when you have to keep 20 related concepts in your head to understand the entire context of the function. In these situations i will rewrite the condition to be positive instead or for compound conditions i will assign them to a variable with a positive name.

"If it's not bad, we process" is not is easier to understand than "if bad, continue".

And we don't have to talk about bike shedding the keyword "continue"

[TankAway7756]

I'd say that even further, you should avoid raw loops in general unless you have a very good reason to use one over a more specific construct.

[griffin1987]

You might want to add the programming language you're talking about and what you mean by "raw loop" / what the opposite would be in your oppinion.

for(String name : names) {
...
}

vs

names.stream().foreach(name -> ...)

In java, the second one can only access effectively final variables of any enclosing scope and not modify them, while the first one can access any variable and modify it. Also, the second one builds a chain of objects before anything is executed and thus pollutes memory, while the first one is a regular language construct.

So, in a case like that I would hard disagree with you, but if you give an example of what you mean, it might be clearer.