GSoC idea: metrics and visualization support in KDevelop (Opinions ?)
zwabel at googlemail.com
Mon Mar 24 01:43:37 UTC 2008
On Monday 24 March 2008 01:11:32 Sandro Andrade wrote:
> Hi all,
> I was wondering about some interesting GSoC proposal for KDevelop and I
> came up with ideas about metrics and visualization support. At first
> glance, the aim would be to provide design metrics mechanisms which
> estimate the quality, complexity, and effort required by future changes in
> a given development project. The project would involve: design and
> implementation of a language-independent core for metric extraction (may be
> by keeping a meta-model of the source-code), selection of some most
> representative object-oriented metrics (probably regarding size,
> complexity, coupling, and inheritance), definition of reference points for
> bad and good (and intermediate) metric values, and implementation of some
> metric visualization support.
> I'm aware that this can be considered a very broad idea, but I believe that
> providing a extensible and concise metric extraction and visualization core
> would make future inclusion of new metrics and visualizations easier.
Hi! To me personally, this whole thing sounds a little too abstract to imagine
what the exact use of the whole thing within KDevelop would be. ;)
Given the du-chain we have in kdevelop-4, and everything parsed completely, it
should however be possible to evaluate such things using exactly that
information without too much effort. Currently there is only one
language(C++) that does a complete enough parsing for that, but we cannot yet
parse a whole project because it takes too much memory. Also the parsing
isn't "perfect" yet. So if you'd work on such a thing, you might be missing a
foundation to be actually able to test the stuff.
Also, at least me personally, I'd prefer seeing projects on KDevelop this year
that work on one of the important missing peaces, or on fixing up the
foundation, instead of adding "cool" stuff built on an incomplete/buggy
foundation. KDevelop-4 is currently in a state where it finally needs to
become "useful". :)
Just by the way, me I'm going to apply this year for a C++ support related
project, to fix the "incomplete foundation" problem mentioned above, at least
Here is some ideas what might interesting this year from my personal POV:
- Python support(Integrate debugger, integrated python shell, finishing the
python code completion)
- User Interface Improvements: Think about the workflow, file management,
multi-screen support, etc.
- Project management improvements: Make the cmake support in kdevelop-4 as
easy as automake support in kdevelop 3(Allow adding targets, files, etc.
- Distribution integration(see
Just by the way this doesn't mean that your initial Idea wouldn't work. It
just sounds a little too abstract to imagine how exactly it would look, how
it could be implemented, whether the needed foundation is there, and whether
it is feasible to be implemented during SOC.
More information about the KDevelop-devel