Loop-switch sequence

A loop-switch sequence (also known as the for-case paradigm or Anti-Duff's Device) is a programming antipattern where a clear set of steps is implemented as a switch-within-a-loop. The loop-switch sequence is a specific derivative of spaghetti code. It is not necessarily an antipattern to use a switch statement within a loop—it is only considered incorrect when used to model a known sequence of steps. The most common example of the correct use of a switch within a loop is an inversion of control such as an event handler. In event handler loops, the sequence of events is not known at compile-time, so the repeated switch is both necessary and correct (see event-driven programming, event loop and event-driven finite state machine). This is not a performance antipattern, though it may lead to an inconsequential performance penalty due to the lack of an unrolled loop. Rather, it is a clarity antipattern, as in any non-trivial example it is much more difficult to decipher the intent and actual function of the code than the more straightforward refactored solution.

A loop-switch sequence (also known as the for-case paradigm or Anti-Duff's Device) is a programming antipattern where a clear set of steps is implemented as a switch-within-a-loop. The loop-switch sequence is a specific derivative of spaghetti code. It is not necessarily an antipattern to use a switch statement within a loop—it is only considered incorrect when used to model a known sequence of steps. The most common example of the correct use of a switch within a loop is an inversion of control such as an event handler. In event handler loops, the sequence of events is not known at compile-time, so the repeated switch is both necessary and correct (see event-driven programming, event loop and event-driven finite state machine). This is not a performance antipattern, though it may lead to an inconsequential performance penalty due to the lack of an unrolled loop. Rather, it is a clarity antipattern, as in any non-trivial example it is much more difficult to decipher the intent and actual function of the code than the more straightforward refactored solution. ==Example== An event-driven solution would implement a listener interface: String key = null; String value = null; List params = null; int column = 0; public void addToken(token) { // parse a key, a value, then three parameters switch (column) { case 0: params = new LinkedList (); key = token; break; case 1: value = token; break; default: params.add(token); break; } if (++column >= 5) { column = 0; completeRow(key, value, params); } } But without the listener, it becomes an example of the antipattern: // parse a key, a value, then three parameters String key = null; String value = null; List params = new LinkedList (); for (int i = 0; i And here is the refactored solution: // parse a key and value String key = stream.parse(); String value = stream.parse(); // parse 3 parameters List params = new LinkedList (); for (int i = 0; i ==References==

Text derived from https://en.wikipedia.org/w/index.php?oldid=1138976121 under CC BY-SA 4.0; modifications have been made.