>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 members). 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.
