5 ms·

Saw a perfect example of this on stackoverflow (or stackexchange I forget which). But someone posted some actual code, it had a switch statement, only 3 case o

Saw a perfect example of this on stackoverflow (or stackexchange I forget which). But someone posted some actual code, it had a switch statement, only 3 case options, about 7 lines and if the switch didn't hit, throw exception after "I would be careful with that switch, it looks like a code smell, this is how I would do it: 2+ interfaces, 3+ classes, abstract this, factory that and over 100 lines of code. I just refuse to believe a simple switch that everyone can understand in about 1 second is not the better solution to some complex code, even if it does use a "pattern"

maxxxxx 10y ago
Same with goto. Wasn't there recently an article about if-less" development where if gets replaced with callbacks?
- h_r 10y ago
  If you're doing OOP this can mean leveraging polymorphic behavior rather than switching on data or data types. It's good to keep in mind even if it doesn't fit every single case.
vog 10y ago
Can you find the actual link, by any chance? I'd love to see that one in real.
curun1r 10y ago
A switch can increase the cyclomatic complexity of code and make it difficult to visualize how code flows at runtime. It may be the best solution, but often violates the single responsibility principle. What is best is often situational and depends on a developer's code aesthetic. But a single switch statement is useless in isolation, so one can't evaluate whether it's appropriate in isolation without looking at the context in which it's used.
- TeMPOraL 10y ago
  > A switch can (...) make it difficult to visualize how code flows at runtime You mean visualize with a tool, or in your head? If the former, I'd love to know of a tool for visualizing code flow. If the latter, then I think a switch - with entry and exit points, and all code paths clearly visible together on one screen - is much easier to visualize than an implicit branching hidden behind interfaces, requiring you to jump around definitions of several objects.
  - curun1r 10y ago
    It may be easier, when considering the switch in isolation. But code is rarely considered in isolation. A switch creates multiple possible code paths. Combine it with other switch statements and the possible code paths grow geometrically. This is the theory behind measuring cyclomatic complexity. When I said visualize, I meant primarily in the programmer's mind, but there are other tools that help. Code coverage tools ensure that all branches of code are tested, but fail to ensure that all permutations of all branches get tested. This is something where fuzzing tools can attempt to ensure that all branches are taken, but will quickly run into the limitations of the underlying machine if the cyclomatic complexity is too high. Beginning programmers learn flow control very early in their development. Most will also learn fairly quickly that creating a rat's nest of ifs and switches can become difficult to reason about. It's for that reason that we learn abstractions that help us increase the complexity of the tasks we can solve without increasing the complexity of the code we have to understand.
    - Silhouette 10y ago
      A switch creates multiple possible code paths. Combine it with other switch statements and the possible code paths grow geometrically. That is certainly true, but it is equally true of any mechanism for making those decisions. With some mechanisms, like if-else and switch-case, the decisions are explicit. With others, like virtual function dispatch, the decisions are implicit. Either way, the decisions are still being made and the combinatorial properties of multiple decisions are still the same.
- 10y ago
Silhouette 10y ago
Indeed. One of the reasons that I, for one, tend to be very critical of that sort of advocacy is that one day someone less wary will read it, and they will think it is good advice because it looks convincing and comes from someone with a reputation in the industry, and then they might become the next junior developer I have to mentor or the next ex-senior-developer whose code I have to fix before I can get on with doing some real work. It's happened before, and no doubt it will happen again.
tbrownaw 10y ago
How is someone being clearly facetious a perfect example of anything?
sanderjd 10y ago
Without having seen this specific SO thread, I can easily imagine both 1. agreeing that the 7-line switch-based code is the better solution to a little SO-question-sized problem, and 2. finding that same solution with no abstraction inflexible and "smelly" in a huge codebase very actively developed by tons of people. Context matters, and knowing what the context is currently and predicting what it will be in the future are some of the tough things about programming.
- hinkley 10y ago
  I used to have answers, now most of the time I say 'it depends'. Some days I wish I could take the blue pill and not have to try to explain the nuances of context. I think objectively the code is better for it but sometimes it takes more social sophistication than I possess. I end up spending too much time talking in post mortems and it all sounds like 'I told you so'
- BeetleB 10y ago
  This. If it's a small program with limited scope, switches are fine. If it's part of a much larger program, there's a chance that switch will explode to switching on the same thing all over the codebase. However, I think GP's point is valid. If during a code review I have a switch and it makes no sense to abstract it, I'd smack the reviewer on the head if he/she wants me to "fix" it.

maxxxxx 10y ago

Same with goto. Wasn't there recently an article about if-less" development where if gets replaced with callbacks?

h_r 10y ago
If you're doing OOP this can mean leveraging polymorphic behavior rather than switching on data or data types. It's good to keep in mind even if it doesn't fit every single case.

vog 10y ago

Can you find the actual link, by any chance? I'd love to see that one in real.

curun1r 10y ago

A switch can increase the cyclomatic complexity of code and make it difficult to visualize how code flows at runtime. It may be the best solution, but often violates the single responsibility principle. What is best is often situational and depends on a developer's code aesthetic. But a single switch statement is useless in isolation, so one can't evaluate whether it's appropriate in isolation without looking at the context in which it's used.

TeMPOraL 10y ago
> A switch can (...) make it difficult to visualize how code flows at runtime You mean visualize with a tool, or in your head? If the former, I'd love to know of a tool for visualizing code flow. If the latter, then I think a switch - with entry and exit points, and all code paths clearly visible together on one screen - is much easier to visualize than an implicit branching hidden behind interfaces, requiring you to jump around definitions of several objects.
- curun1r 10y ago
  It may be easier, when considering the switch in isolation. But code is rarely considered in isolation. A switch creates multiple possible code paths. Combine it with other switch statements and the possible code paths grow geometrically. This is the theory behind measuring cyclomatic complexity. When I said visualize, I meant primarily in the programmer's mind, but there are other tools that help. Code coverage tools ensure that all branches of code are tested, but fail to ensure that all permutations of all branches get tested. This is something where fuzzing tools can attempt to ensure that all branches are taken, but will quickly run into the limitations of the underlying machine if the cyclomatic complexity is too high. Beginning programmers learn flow control very early in their development. Most will also learn fairly quickly that creating a rat's nest of ifs and switches can become difficult to reason about. It's for that reason that we learn abstractions that help us increase the complexity of the tasks we can solve without increasing the complexity of the code we have to understand.
  - Silhouette 10y ago
    A switch creates multiple possible code paths. Combine it with other switch statements and the possible code paths grow geometrically. That is certainly true, but it is equally true of any mechanism for making those decisions. With some mechanisms, like if-else and switch-case, the decisions are explicit. With others, like virtual function dispatch, the decisions are implicit. Either way, the decisions are still being made and the combinatorial properties of multiple decisions are still the same.
10y ago

Silhouette 10y ago

Indeed. One of the reasons that I, for one, tend to be very critical of that sort of advocacy is that one day someone less wary will read it, and they will think it is good advice because it looks convincing and comes from someone with a reputation in the industry, and then they might become the next junior developer I have to mentor or the next ex-senior-developer whose code I have to fix before I can get on with doing some real work. It's happened before, and no doubt it will happen again.

tbrownaw 10y ago

How is someone being clearly facetious a perfect example of anything?

sanderjd 10y ago

Without having seen this specific SO thread, I can easily imagine both 1. agreeing that the 7-line switch-based code is the better solution to a little SO-question-sized problem, and 2. finding that same solution with no abstraction inflexible and "smelly" in a huge codebase very actively developed by tons of people. Context matters, and knowing what the context is currently and predicting what it will be in the future are some of the tough things about programming.

hinkley 10y ago
I used to have answers, now most of the time I say 'it depends'. Some days I wish I could take the blue pill and not have to try to explain the nuances of context. I think objectively the code is better for it but sometimes it takes more social sophistication than I possess. I end up spending too much time talking in post mortems and it all sounds like 'I told you so'
BeetleB 10y ago
This. If it's a small program with limited scope, switches are fine. If it's part of a much larger program, there's a chance that switch will explode to switching on the same thing all over the codebase. However, I think GP's point is valid. If during a code review I have a switch and it makes no sense to abstract it, I'd smack the reviewer on the head if he/she wants me to "fix" it.