code-forensics
code-forensics copied to clipboard
cyclomatic complexity for other languages
Silvio, what are your thoughts on adding support for more languages? What approach would you prefer/recommend?
That's entirely possible. Although cyclomatic complexity is not the primary objective of a code-forensics investigation, its metrics are featured in a few analyses and sure can help to better understand the evolution of a codebase. From an implementation standpoint, I've written code-forensics with that in mind, and as long as a command line tool is available that can compute the cyclomatic complexity for a particular programming language, its integration into code-forensics should be fairly simple. What language/languages would you target?
True - we can use some other tools for that; I was thinking of Java and C# to start with and was wondering if there was a requirement for the output and how to package helpers to extend the current 2 supported... Adam also looks at negative space in his book - do you have plans for that?
@smontanari @jdevoo Java support to analyse complexity would be highly interesting for me. I was wondering why you have not used the whitespace / line complexity analysis instead which should be language agnosic and easier to implement. This is what Adam Tornhill suggested anyways. There is also a tool available, but I really don't know how efficent it is. https://github.com/adamtornhill/indent-complexity-proxy
@jeskoriesner it's always possible to add whitespace technique as an alternative, language agnostic tool. However I've never tried it myself to really tell how effective it is, and we also have the sloc analysis that can give an language neutral idea of complexity trend. Happy to look into adding java if anyone can suggest me a tool that can quickly produce a simple report and can be run from a shell command line.
@smontanari would you have recommendations on how to write a task or one I should look at? I ask because this repo may be a starting point to incorporate Java?
I believe that in order to understand how to produce a complexity report for code-forensics the best place to start is the report that is created to feed the diagram, i.e. a top-down approach. If you run the javascript or ruby complexity report task you will produce a report file in the temp folder. Look at the data of the report and you'll see that the intention is to produce particular metrics for each entry, each entry being, in the case of java, a class, or maybe an interface with default methods. For each entry we want at a minimum to capture the total complexity. If available (or computable) we would like to also provide an overall average complexity. Even better, depending on how smart the tool we use is, the complexity at method/function level. The result of the analysis of a single file is required to be a javascript object like this:
{
path: 'path/to/file',
totalComplexity: 5.3, // number representing the aggregate cyclomatic complexity,
averageComplexity: 2.4 // number representing the average cyclomatic complexity per method/function/block,
methodComplexity: [
name: 'function/method/block identifier',
complexity: 2.1 // number representing the cyclomatic complexity of the block of code
]
}
How you implement the logic to generate such data is dependent on the output of the tool you are using.
In code-forensics the modules responsible to perform such operation are in lib/analysers
. For ruby I implemented the flog
analyser, for javascript I implemented the escomplex
analyser.
For instance in the case of ruby I created a parser to translate the flog output to what I need. If you have ruby and install the gem flog you can try and run the flog command on a ruby file and look at its output to understand what the flog parser is doing.
Having said all that, I'm more than happy to help on the javascript/code-forensics side of things, as long as there is a command line tool that can produce meaningful data.
I haven't tested the java-complexity
utility you have mentioned, but it'd be helpful if anyone could run some tests to confirm its reliability and performance, such as, does the tool support the old as well as the latest versions of the java language? Is it fast? Does it hang or leak memory etc.? Does it produce metrics at method level or only at class level?
I can do some of that but I've been (and still am) pretty flat out with work in recent months and haven't had as much time to dedicate to code-forensics as I wanted to