Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
Cyclomatic complexity can be helpful in keeping us away from writing complex code that can be more error prone, more complex to be tested and harder to reason about. I would give a special attention for the latter one as it implies in low readability and high maintenance costs. For example, an if/else statement is commonly used as:
if THIS then do some logic in order to return THAT
if THAT then do some logic in order to return THIS
if SOMETHINGELSE then do some logic in order to return THAT and THISelse do some logic in order to return THIS and THAT
Usually each block contains some logic in order to do something. Naturally each piece of logic requires attention as one must understand what a block is doing, what is its purpose and if the expected result is what is being produced. Now imagine a single function with twenty conditional statements, where each one produces a single different result, and you have to explain (and remember) what are all the values that this function returns and under which conditions. Probably you already got the point.
However, note that cyclomatic complexity doesnât try to determine how complex each path contained in a control flow graph is. It doesnât try to understand each block of your programâs architecture, instead, it focus on how most of the programs are written and assumes that all cases are equal. In order to be helpful it assumes that all execution path contains a specific and unique piece of logic, as most of the time, it is the case. I have been thinking about that point since I started programming in Go. Following the error handling pattern we use in Golang, check this other example:
THIS, ERR := fnGetThis()if ERR then return error
THAT, ERR := fnGetThat()if ERR then return error
SOMETHINGELSE, ERR := fnGetSomethingElse()if ERR then return error
WHATEVER, ERR := fnGetWhatever()if ERR then return error
do some logic in order to produce the expected result using THIS, THAT, SOMETHINGELSE and WHATEVER
It seems to me that none of the if statements that only return an error, and has no extra logic, can be error prone, nor is difficult to reason about, nor makes it harder to explain the purpose of that whole block. It does one thing, once everything it needs works.
Maybe a better cyclomatic complexity analysis would be presented if we could choose to discard the cases where returning an error is the only thing that is done, and nothing else. As the real complexity to generate those errors is not written there, but instead, in the functions that are being called.
I would like to hear more thoughts on this subject as my goal here is to discuss about it. So, feel free to leave a comment đ.
Thoughts on cyclomatic complexity in Golang's world was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.