>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 used for 
cyclomatic complexity is 10 which seems like a reasonable, but not magical, 
upper limit. Programmers have been required to calculate complexity as they 
create software modules. When the complexity exceeded 10 they had to either 
recognize and modularize subfunctions or redo the software. The intention 
was to keep the "size" of the modules manageable and allow for testing all 
the independent paths (which will be elaborated upon in Section VII.) *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.* It has been interesting to note how 
individual programmer's style relates to the complexity measure. The author 
has been delighted to fmd several programmers who never had formal training 
in structured programming but consistently write code in the 3 to 7 
complexity range which is quite well structured. On the other hand, FLOW 
has found several programmers who frequently wrote code in the 40 to 50 
complexity range (and who claimed there was no other way to do it). On one 
occasion the author was given a DEC tape of 24 Fortran subroutines that 
were part of a large real-time graphics system. It was rather disquieting 
to fmd, in a system where reliability is critical, subroutines of the 
following complexity: 16, 17, 24, 24, 32, 34, 41, 54, 56, and 64. Mter 
confronting the project members with these results the author was told that 
the subroutines on the DEC tape were chosen because they were troublesome 
and indeed a close correlation was found between the ranking of subroutines 
by complexity and a ranking by reliability (performed by the project 

On Sunday, September 27, 2015 at 10:26:48 PM UTC-4, Henry wrote:
> Hi,
> I am trying to come up with a good cyclomatic complexity number for 
> typical Go codes. Go is a unique language where its explicit error handling 
> results in a higher cyclomatic number and yet its simple syntax and 
> orthogonal design allows Go to still be readable even at a higher 
> cyclomatic number. I am interested in knowing whether McCabe's number of 10 
> is still a good general rule for typical Go projects. 
> In my own codes, I find McCabe's number of 10 is a bit limiting for 
> complex functions. While I can refactor the functions to get to 10 or less, 
> it generally results in a less readable code. There is usually too much 
> fragmentation with important parts of the codes being described elsewhere 
> in various sub-functions. Although Go codes are still readable at 15, I 
> think 12 is a good ideal number for typical Go functions. I am trying to 
> test whether 12 is indeed the ideal cyclomatic number for Go or whether 
> McCabe's 10 is still the ideal.
> If you have time, feel free to participate and share your findings. The 
> tool I use to measure cyclomatic complexity is 
> https://github.com/fzipp/gocyclo.
> Thanks.
> Henry

You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to