3 ms·

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 vio

by 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.
douche 10y ago
Switches seem to increase the metrics for cyclomatic complexity absurdly in all of the tools I've used to measure it, compared to directly equivalent constructions, like a raft of else-ifs or indexing into a lookup dictionary. Things like a simple mapping between two slightly incompatible enums will have whopping cyclomatic scores, despite being incredibly simple to reason about. Taking that kind of a metric to heart can lead to a different flavor of cargo-culting.

by curun1r 10y ago

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.

douche 10y ago

Switches seem to increase the metrics for cyclomatic complexity absurdly in all of the tools I've used to measure it, compared to directly equivalent constructions, like a raft of else-ifs or indexing into a lookup dictionary. Things like a simple mapping between two slightly incompatible enums will have whopping cyclomatic scores, despite being incredibly simple to reason about. Taking that kind of a metric to heart can lead to a different flavor of cargo-culting.