Advanced Statistics and Ranking

[bonanza123]

would it be possible to extend the ranking and statistics in the following way?

• Differentiate in the general statistics between "actual code" and "comments" in addition to the already existing "Insertions" and "Deletions"
• Allow ranking of the authors by: Insertions, Deletions, Lines of actual code, comments or code complexity (provided by metrics)

[adam-waldenberg]

Hi @bonanza123. You mean show insertions ad deletions in the timeline ? Or do you simply mean the amount of inserted / deleted comments ? I don't see the use case for this functionality and what it would contribute over the "percentage in comments" calculation we already have.

Sorting can already be done in the HTML output in the stable branches (I'm unsure of the status in the master branch, as the HTML output is being rewritten).

[bonanza123]

@adam-waldenberg, Ahh I see.. I mean e.g. in the image, it would be nice to have additional columns in the second section / paragraph showing also current complexity of survived code on a per-user basis.

[adam-waldenberg]

@bonanza123 You mean to show the cyclomatic complexity metric per-user ? I think that would be impossible to calculate, as most of the time, many authors edit the same file and/or method/function. So how would the attribution work ? Who get's "blamed" for any added complexity ?

[adam-waldenberg]

@bonanza123 It's an intersting thought, but the question is if it can be done in any logical way.

[bonanza123]

@adam-waldenberg Maybe its a stupid idea but what about doing it proportional to the number lines where each author contributed to. E.g. if there is a code like

if ( x > 0 ) {
     f(x); // this line has been edited by author A and B
     g(x); // this line has only been edited by author A
}

Then I would say author A gets + 2 lines of complexity and author B only + 1.

[adam-waldenberg]

@bonanza123 Doubtful. Another way to look at it is that the person that added the if statement is the culprit as he is the one that actually increased the complexity by adding another nesting.

It's an interesting idea, but I'm not quite sure what the "correct" and most logical way to implement it would be.

[adam-waldenberg]

Let's keep the issue open for now. It might be interesting to look into this. Also, maybe somebody else has some additional ideas for a solution to this.

[wawiesel]

Hey guys, just started using this tool today and was particularly happy to see this complexity measure. For our team, when we introduce these metrics, it will be

1. a way to find some hotspots that need work and
2. give a warm fuzzy idea about the delta complexity introduced by a stack of changes slated to be merged into master.

So for 2, basically you just have to look at the commit-by-commit complexity, with the change in complexity due to a single commit attributable to a single author.

If you handled it like this, you would see the complexity bump up with the commit when the if was introduced which could then be attributed to the author of the commit.

This is probably something you want to be really clear about enabling because it will take forever, but man would it be cool!

[adam-waldenberg]

Thanks @wawiesel. Interesting idea - but would also mean we would have to add a whole new section to the report for the complexity measurements. And as you say, it would be incredibly painful and take quite a lot of time :). However - it might be something to think about once the incremental stats discussed in #22 are working well.