Content deleted Content added
No edit summary |
Marcocapelle (talk | contribs) removed Category:Anti-patterns; added Category:Computer programming using HotCat |
||
(17 intermediate revisions by 15 users not shown) | |||
Line 1:
{{Orphan|date=October 2022}}
A '''loop-switch sequence''' (also known as the '''for-case paradigm'''<ref>[http://thedailywtf.com/Articles/Switched_on_Loops.aspx Switched on Loops] at [[The Daily WTF]]</ref>) 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]].▼
▲A '''loop-switch sequence'''<ref name="LEVEL ">{{cite web | url=https://levelupcode.wordpress.com/avoid/loop-switch-sequences/ | title=Loop-switch sequences | date=30 November 2013 | publisher=LEVEL UP CODE | accessdate=11 April 2016}}</ref> (also known as the '''for-case paradigm'''<ref>[http://thedailywtf.com/Articles/The_FOR-CASE_paradigm.aspx The FOR-CASE paradigm] and [http://thedailywtf.com/Articles/Switched_on_Loops.aspx Switched on Loops] at [[The Daily WTF]]</ref> 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 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]]).▼
▲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]]).
Note that this is not a performance antipattern, though it may lead to an inconsequential performance penalty due to the lack of an [[Loop unwinding|unrolled loop]]. Rather, this 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==
Here is an example of the antipattern:▼
An event-driven solution would implement a [[Observer pattern|listener interface]]:
<
String key = null;
String value = null;
List<String> params = null;
int column = 0;
public void addToken(token) {
// parse a key, a value, then three parameters
switch (column) {
case 0:
params = new LinkedList<String>();
key = token;
break;
case 1:
value = token;
break;
default:
params.add(token);
break;
}
if (++column >= 5) {
column = 0;
completeRow(key, value, params);
}
}
</syntaxhighlight>
// parse a key, a value, then three parameters
String key = null;
Line 27 ⟶ 58:
}
}
</syntaxhighlight>
And here is the refactored solution:
<syntaxhighlight lang="java">
▲<source lang="java">
// parse a key and value
String key = stream.parse();
Line 41 ⟶ 71:
params.add(stream.parse());
}
</syntaxhighlight>
==References==
<references />
[[Category:
|