3

I know there have been a number of discussions of whether break and continue should be considered harmful generally (with the bottom line being - more or less - that it depends; in some cases they enhance clarity and readability, but in other cases they do not).

Suppose a new project is starting development, with plans for nightly builds including a run through a static analyzer. Should it be part of the coding guidelines for the project to avoid (or strongly discourage) the use of continue and break, even if it can sacrifice a little readability and require excessive indentation? I'm most interested in how this applies to C code.

Essentially, can the use of these control operators significantly complicate the static analysis of the code possibly resulting in additional false negatives, that would otherwise register a potential fault if break or continue were not used?

(Of course a complete static analysis proving the correctness of an aribtrary program is an undecidable proposition, so please keep responses about any hands-on experience with this you have, and not on theoretical impossibilities)

Thanks in advance!

| improve this question | |
  • 1
    Is there an idiomatic way using the macros/libraries available to developers of your project to find an element in a series that matches a certain criterion and then stop without using break and without introducing more local variables? If not, then making break harder to use is going to make writing at least one common code pattern harder. – Mike Samuel May 17 '12 at 17:18
  • 1
    break and continue are simple to reflect in control flow graphs. In fact, I don't think there would be significant differences between the CFGs of loops using break/continue and those using if and flags to achieve the same control flow. So any static analysis tool that uses CFGs should treat them the same way - of course, I don't know if any actually do, otherwise I'd post an answer. – user7043 May 17 '12 at 17:53
  • @delnan: yes, there is a difference in the CFGs. The code with a break has a branch out of the middle, and the one with the if does not. Worse, the one with flags is harder to code (you have to declare the flag, set it to false, set it to true to escape the loop, explicitly test the flag at the loop boundary... what's to like about this?) "break" and "continue" are good ideas. "break <loop label>" and "continue <looplabel>" are better ideas, because it is clear which construct is being exited/continued. The effective behavior isn't different, but the if version is more often miscoded. – Ira Baxter May 18 '12 at 2:34
4

I've used Coverity on a number of fairly large code-bases and not found the occasional use of break or continue to cause false positives. However in most code-bases I've worked with break and continue have only been used lightly and generally only in fairly simple ways.

My concern with the use of break and continue would be code readability. In general I suspect that static analysis tools cope better than people at dealing with their use. I would discourage them for that reason, not for static analysis.

In practise I've found that code requiring either use of break and continue or excessive indention can probably be written in a better way anyway, although there are cases where it can significantly aid readability.

| improve this answer | |
0

I think this depends on exactly how the static analysis is being done. For example, in Java many static analyses are done on Java bytecode, rather than on the Java source directly. This simplifies many aspects of analysis because it uses unstructured control-flow (i.e. with conditional and unconditional branching). Here, break and continue statements are compiled away into unconditional branches and so the analyzer doesn't even notice them.

However, if the static analysis is operating on source code directly, then break and continue statements may cause a loss of precision. But, equally, they may not.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.