GSoC idea: metrics and visualization support in KDevelop (Opinions ?)

[David Nolden]

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 
for C++.

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. 
through UI)
- Distribution integration(see 
http://techbase.kde.org/index.php?title=Projects/Summer_of_Code/2008/Ideas#KDevelop)

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.

Greetings, David