https://en.wikipedia.org/wiki/Cyclomatic_complexity has the following definition

The cyclomatic complexity of a section of source code is the number of linearly independent paths within it

The current version of the code does not count linearly independent code paths. Instead it counts branch points. This is different. For example, cyclomatic complexity of

if a {
  if b {
  } else {
  }
} else {
}

and

if a {
} else {
}
if b {
} else {
}

must be different, but current implementation would return same value.

This PR rewrites the computation algorithm.

For editor/IDE tooling, recursing by default can be very very slow. I think, as with many other tools, that in conjunction with find -type d all use cases are satisfied.

This PR adds a flag to allow a user to easily skip test files during analysis for cases when the critical component is the code under test and not the tests themselves.

This PR implements the possibility to ignore files that match the given regular expression. Fixes #9, #4 (generic approach).

Example:

$ gocyclo -ignore "yacc|\.pb\.|Godeps" .

Hello, @fzipp.

I think highly nested construction should not give the same amount of points as the first-level one. Flat code is less complex than nested, isn't it? For illustration, here is a code fragment that has complexity of 11:

package zzz

func smth(obj interface{}) {
    switch obj.(type) {
    case int:
        ProcessInt(obj)
    case int8:
        // ..
    case int16:
    case int32:
    case int64:
    case uint:
    case uint8:
    case uint16:
    case uint32:
    case uint64:
    }
}

Pretty simple and straight-forward function, isn't it? Now here is another one that is "less complex" (level is 10):

package xxx

func smth(i int) {
    if i < 1 {
        if i < 2 {
            if i < 3 {
                if i < 4 {
                    if i < 5 {
                        if i < 6 {
                        } else {
                        }
                    } else {
                    }
                } else {
                    if i < 5 {
                    } else {
                    }
                }
            } else {
                if i < 4 {
                    if i < 5 {
                    } else {
                    }
                } else {
                }
            }
        } else {
        }
    } else {
    }
}

For me, personally, this doesn't look like a less complex function. What do you think?

My opinion is complexity should grow geometrically with every level of nesting. But requirements for flat code may be loosed up.

Background: https://github.com/alecthomas/gometalinter/issues/238

In short, when gocyclo is executed automatically (for ex. by gometalinter in CI) and it output is used to decide to pass or to fail automatic build we need more control than just single -over N value applied to all packages in current project.

Please add a feature to either completely skip gocyclo on per-function basis, or overwrite value of -over N argument on per-function basis. For example, check how another tool use annotations: https://github.com/GoASTScanner/gas#annotating-code

Add a flag which will exclude testing code from the generated report.

I think it is useful to be able to optionally exclude tests from the report. I am suggesting this be a flag and optional since the exclusion or inclusion of test source code is dependant on the developer(s) or project maintainer(s) and this would give flexibility to whatever they decide.

I noticed that functions declared as variables are not included. It would be nice if they were. We use variable functions a lot for testability and mocking.

According to https://golang.org/cmd/go/: directory and file names that begin with "." or "_" are ignored by the go tool, as are directories named "testdata".

Fixes #6

We are using this project for Fyne, but we need to remove the vendor folder (https://github.com/fyne-io/fyne/blob/7229e889d49c81a83b0b7e09400837f67f6ddad5/.github/workflows/static_analysis.yml#L21) to ignore picking up things in packages that we do not maintain. It would be great if gocyclo could do like many other Go tools and simple ignore looking in the vendor folder.

Not just an issue, but it would be nice to have a switch to avoid counting constructs clearly related to mere error checking and returning, for example IF block with less that 3/4 lines testing just err != nil could be not counted in complexity. ES: if err != nil { log....... return nil,err // or return fmt.Errorf("sfsdfsdf %w", err) }

While technically correct, in my opinion if err != nil checks don't really add complexity to a function from the programmers' standpoint. It would be nice to have an option to ignore these statements in functions.

I usually use local functions to split my main function to multiple part and group related functions together. However, gocyclo always report the complexity of my main function is high (e.g: 20) while it looks lower if we remove the local functions.

Can we have an option to exclude the local functions from calculation?

Can we have a CLI parameter to let gocyclo exit with non-zero value in case there are files meet -over criteria?

I'm thinking of using gocyclo in CI job, instead of pipe output to a file, then check if the file is empty or not to determine offending files, it will be great to have an option mentioned above.

It is a nice to have to provide a wiki with academic definitions (as described in #10) and provide some examples of usage (with code and expected results)

It would be nice if function literals were assigned a complexity separate from the function declaration they were nested inside. This will require giving the nested function literals pseudo-names. E.g., the second function literal nested inside func Foo, might given pseudo name like "Foo.funcLit#2". It might also require using a map[string]stat rather than a []stat and indexing the map with a concatenation of package path with the function name.