Metric presentation

Andreas Pakulat apaku at gmx.de
Mon Sep 15 08:12:25 UTC 2008


On 15.09.08 09:32:24, M Breugelmans wrote:
> On Sun, Sep 14, 2008 at 9:38 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> > On 14.09.08 21:09:18, Manuel Breugelmans wrote:
> >> On Friday 12 September 2008 16:20:03 you wrote:
> >> >
> >> > What do you guys think? Currently I'm leaning towards option 3 but not
> >> > firmly ...
> >>
> >> No opinion on this, anyone? I'll probably go for a pop-up report then.
> >
> > I thought you hate those popups :) Anyway, I guess it would help if you
> > could explain a bit what exactly those metrics are for and what you want
> > to present in the widget.
> 
> Well they allow you to reason on a high level about a software system.
> For now there's only SLOC (source lines of code) grabbed from a perl
> script and McCabe complexity implemented with our c++ parser. The
> second one counts independent paths in the control flow graph of a
> function. Obviously the more paths, the more complex ie lower quality.
> 
> For example I ran this McCabe metric on the Linux kernel which showed
> that 4% of the code is over the acceptable threshold (10 paths). Qt4
> on the other hand has significantly lower quality with 8% being
> unreadable. The offenders are prime refactor opportunities.
> 
> So what does this widget have to show? For now some kind of table or
> tree with the metric source-entity (be it file, class, function) and
> the associated value(s),

Thanks. Ok, so I think what we really want is Alex new Ui
design+drag'n'drop support, which would allow the user to choose among
the 3 options you had :) So for now I think either a dialog or a
central-area-view are the best due to the possible amount of data to be
displayed.

Andreas

-- 
You are magnetic in your bearing.




More information about the KDevelop-devel mailing list