Avoiding the break statement

Some coding guidelines and best practices advice against the use of continue and break statements.

With continue the solution is easy, placing an if (or if it existed to call continue, negate it to execute the code).

But with break, it is not always so easy. Some times, in fact the resulting code is more messed up or harder to read (usually because of too much ifs), so I use break sometimes in my code if avoiding it is going to be worse for readability.

The most common case of using the break statement is looping through an indexed array of elements searching for something:

int[] numbers = { 1, 2, 3, 4, 5 };
for
(int index = 0; index < numbers.Length;
index++)

    if (numbers[index] == 3)
    {
       
break;
   
}
}

How to avoid here the break? As one of my bosses taught me, remember the tools at your disposal; A for loop contains three parts: initialization expression, condition expression and loop/increment expression. Nothing forbids us to add additional checks to the condition expression, as in the following improved code:

int[] numbers = { 1, 2, 3, 4, 5 };
bool
found
= false;
for
(int index = 0; index < numbers.Length && !found;
index++)
{
    if (numbers[index] == 3)
    {
        found
= true;
   
}
}

We are short-circuiting the loop, but in a soft and more elegant way (and not commonly seen in the code!).

Comments

25 November 09 by Reed Copsey

# re: Avoiding the break statement

Although many best practices advise against having break or continue statements to avoid more than a single exit point, I also think it's valuable to keep in mind that adding complexity for the sake of following a guideline does exactly the opposite of the intended benefit of having guidelines in the first place.

That being said, when you're using C#, LINQ provides many opportunities to avoid these calls in a more elegant manner, without introducing extra variables purely for the sake of avoiding break/continue statements.  The Where() method used with the Select() overload which provides an indexer can also be used to avoid this situation, since you can have the delegate perform any action, and the index will be provided to you directly.

25 November 09 by Kartones

# re: Avoiding the break statement

Thanks for the info about LINQ, Reed! I definetly should look at LINQ someday, too bad I haven't got enough time for now.

26 November 09 by JuanjoC

# re: Avoiding the break statement

Would not it be better to use a "while"? I think that using a "while" is more "natural" in this case. For example:

int index = 0;

boolean found = false;

while (!found && index < numbers.Length) {

   found = numbers[index++] == 3;

}

26 November 09 by Vicente

# re: Avoiding the break statement

I think the example is too basic to show the point, in this case the for with the 2 conditions looks far worse in my book than the break (how many fors with 2 conditions have you ever seen?).

26 November 09 by Kartones

# re: Avoiding the break statement

@JuanjoC

Yeap, maybe the example was so simple to illustrate using a for with composite conditions. In fact most of the times you can use a while instead of a for, is simply a question of having less lines of code having the for initialize and increment on a single line.

@Vicente

Well, having 60 lines of code inside the for with multiple breaks would probably be a more common example, yes, but no matter if it looks worse for you or not, a composite conditional on the for is perfectly valid but not usually done. But a break in some places is not only bad looking but maybe even forbidden by code policies.

Is not "you must do it" as much as "remember you can do it" (instead of a break).

Leave a Comment

Title (required)  
Name (required)  
Your Website/Blog (optional)
Your Comment (required)  

Captcha
Enter the number of digits on the image above (required)