>
> Refactoring these to fit any cyclomatic limit also makes code worse and
> not worth it. But increasing global limit because of these exceptional
> cases doesn't makes any sense - instead, just add pragma to such func:
> func validateSomething() { // nolint:gocyclo
I feel the same as
Hi!
On Fri, Apr 13, 2018 at 12:41:35PM -0700, Lee Painton wrote:
> The only situation in which this limit has seemed unreasonable is when a
> large number of independent cases followed a selection function (a large
> case statement), which was allowed.
Another situation is function which does val
>From McCabe's paper on the
topic: http://www.literateprogramming.com/mccabe.pdf
These results have been used in an operationalenvironrnent by advising
project members to limit their software modules by cyclomatic complexity
instead of physical size. The particular upper bound that has been use
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
