Is a bit of refactoring in order?

Steven T. Hatton hattons at
Sun Jun 5 20:29:08 UTC 2005

On Sunday 05 June 2005 11:24, Adam Treat wrote:
> On Sunday 05 June 2005 12:51 am, Steven T. Hatton wrote:
> > On Saturday 04 June 2005 23:32, Matt Rogers wrote:
> > > Sure. Good luck finding somebody with time though.
> > >
> > > Matt
> >
> > The problem is, if it doesn't happen, it is going to continue to get
> > worse, and what is now difficult to work with will become impossible to
> > work with. In my mind, this is the most important open source project
> > there is.
> Couple points:
> 1.  What you're pointing out has been the case for a very long time. 
> Still, KDevelop is a pretty good IDE and the best C++ IDE by far.  And the
> code can be read.  It is possible, although not easy in all places.

It's not just a question of readability.  It's also a question of 
maintainability.  There are a lot of things hardcoded in different places 
that could be abstracted and made into a single service class.  For example - 
and I'm sure there are differing opinions on this - I believe all the classes 
that use files should be asking a single file service class for the files.  
And probably not even as files.  I'm thinking DOM Objects.  That should work 
for most if not all text files, and could probably be made to work with 
binary files if we allow for media tags.

> 2.  Look, no one is going to disagree that refactoring is good^TM and we
> should do more of it.  You're not really telling us anything that isn't
> already known.

There are times when its good, and times when its not.  The way I see things, 
the current state of affairs is a hindrance to implementing the kinds of 
functionality I believe is important.  

> 3.  I love KDevelop.  It is the only editor I use for development now a
> days. But there is no way it is the most important open source project out
> there. More important that KDE?  More important than Qt?  More important
> than the Linux kernel?

I don't know if you have much experience with Java IDEs, but the power that a 
tool like JBuilder provides is far beyond what KDevelop currently probides.  
Part of the reason is that Java is designed in such a way that it is easy to 
support these kinds of features.  For one, Java is far less complex.  
Additionally, Java and now C# provides native introspection.

Another problem with support C++ is the stubbornness and even arrogance of C++ 
programmers. When I point out that Java, C#, Python, Perl, Mathematica, and 
Lisp all used standard filename extensions, C++ programmers act as if the 
fact that C++ doesn't have that feature is an advantage.

Many of the pieces to provide much of what introspection provide are in place 
in KDevelop.  What introspection is based on, to a large extent is having 
descriptor objects for all the parts of the program, and treating just about 
everything as an object.  Even a method is an object.  What KDevelop does is 
to build up the descriptor objects representing the C++ components from the 

As regards KDevelop being the best IDE for C++, I can't say a lot.  I don't 
have much to compare it with.  But there are certain features that currently 
prevent me from using KDevelop very much.  One of them is the way it does 
code frommatting.  As far as editors go.  I really like the OTE. 

> 4.  Dig in.  Seriously.  No one is going to object to the code being made
> more readable and improved.

I hope to find time to do some of that.  I only have about a year of real C++ 
experience, so I'm just getting to the point where I can really get a handle 
on the code.

> Of course, what is probably going to happen is the KDevelop meeting coming
> up will determine the direction of the project.  Some are pushing for a
> near-to-complete rewrite.  Others want to see the current code base
> continue... be ported, improved and extended.

Rewriting isn't always rewriting.  At least for me.  Often it means 
rearranging.  What I've been musing about is the benefit of trying to make 
all the components such as the PCS creation dialog into standalone capable 
apps.  That is, the could run without the rest of KDevelop running.  Kind of 
like the way Cervisia runs on its own or in Konqueror. (and extending 
Cervisia to support SVN is a very good idea).

> Personally, I want to see the current code base live on, but rewrite a
> substantial part of the cpp language part.  Roberto's parser will be
> integrated and we'll need to rewrite that.  Plus, the new Kate changes are
> going to make it hard to do anything less than a complete rewrite of that
> part.  Other parts of the code base are in relatively good shape and there
> is no reason, I feel, to start with a blank slate in these cases.
> If I were to recommend one thing we do is to concentrate on doing what we
> do... WELL... and leave the more trivial features, capabilities out unless
> we can do them WELL too.
> Adam

Oh, I think there have been a lot of core features neglected while bells and 
whistels have been added.  

More information about the KDevelop-devel mailing list