Loop-switch sequence: Difference between revisions

Revision as of 14:20, 12 July 2007

Latest revision as of 18:27, 12 February 2023

(41 intermediate revisions by 31 users not shown)

Line 1:

{{Orphan|date=October 2022}}

A '''loop-switch sequence''' is a specific derivative of the [[spaghetti code]] programming [[antipattern]] which describes the obfuscating of a clear process of steps with a [[byzantine failure|byzantine]] switch-within-a-loop idiom.

However, it is not necessarily an anti-pattern to use a switch within a loop to build a [[coroutine]] that handles [[Event-driven finite state machine|events using a finite state machine]].

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]].

==Example of antipattern (pseudocode)==

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]]).

<pre>

String key;

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, 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.

String value;

List<String> args;

==Example==

for ( int i = 0; i < 5; ++i )

An event-driven solution would implement a [[Observer pattern|listener interface]]:

{

<syntaxhighlight lang="java">

switch( i )

String key = null;

{

String value = null;

case 0 :

List<String> params = null;

key = stream.parse();

int column = 0;

break;

public void addToken(token) {

case 1 :

value = stream.parse();

// parse a key, a value, then three parameters

break;

switch (column) {

default case 0:

params = new LinkedList<String>();

args.add( stream.parse() );

key = token;

break;

case 1:

value = token;

break;

default:

params.add(token);

break;

}

if (++column >= 5) {

}

column = 0;

</pre>

completeRow(key, value, params);

}

}

</syntaxhighlight>

But without the listener, it becomes an example of the antipattern:

<syntaxhighlight lang="java">

// parse a key, a value, then three parameters

String key = null;

String value = null;

List<String> params = new LinkedList<String>();

for (int i = 0; i < 5; i++) {

switch (i) {

case 0:

key = stream.parse();

break;

case 1:

value = stream.parse();

break;

default:

params.add(stream.parse());

break;

}

}

</syntaxhighlight>

And here is the refactored solution:

<syntaxhighlight lang="java">

// parse a key and value

String key = stream.parse();

String value = stream.parse();

// parse 3 parameters

List<String> params = new LinkedList<String>();

for (int i = 0; i < 3; i++) {

params.add(stream.parse());

}

</syntaxhighlight>

==References==

==Refactored solution (pseudocode)==

<references />

<pre>

String key = stream.parse();

String value = stream.parse();

List<String> args;

for ( int i = 0; i < 3; ++i )

{

args.add( stream.parse() );

}

</pre>

[[Category:Anti-patternsComputer programming]]