Direction of KDevelop4
Richard_Dale at tipitina.demon.co.uk
Mon Sep 12 21:44:04 UTC 2005
On Monday 12 September 2005 19:22, Jens Herden wrote:
> > 1. A clear goal or mission statement ie, "To offer the best KDE/Qt
> > development environment bar none." I think focusing on such a mission
> > statement will provide a better direction for thinking about what we want
> > to see in the new kdevelop.
> I can imagine that a mission statement will have some kind of value for
> marketing. But it would not affect me much and I doubt that many other
> developers would be affected by such a statement.
> But thinking about the direction is indeed a very good idea.
> > 2. Rebranding in the future and a new development name now. As a
> > suggestion, how about 'Orange Julius' for a development name ;)
> I do not care about this. Call it as you like.
> > 3. A source code policy. Currently, KDevelop's source code is
> > atrocious. Even in the new trunk branch, we have a dozen different coding
> > styles with some individual files having more than one coding style.
> > This makes things very hard to read... I think your coding style is
> > brilliant and beautiful. It is very easy to read and clear. I think we
> > should adopt one coding style throughout KDevelop svn and stick to it.
> > Pick one and stick to it. Add Kate modelines for everything and give us
> > an astyle setting to use. BTW, the astyle settings should be made a per
> > project plugin, because different projects people work on have different
> > astyles...
> If a coding style is beautiful or not is definitely a matter of taste.
> Since people have different taste they have different coding style. That is
> life. But I agree that there should be guidelines, but I do not see that
> the whole code must follow the same guidelines. Mixed style in one file
> should be avoided and cleaned if found.
> But personally I have no problems reading code from people with different
> styles. I see coding as a kind of art where people express themself in
> different styles, each with its own advantages and disadvantages.
> > 4. Standards for kdevelop source. No more useless comments. Comments
> > should only be necessary if:
> > a) Something _really_difficult_ or unobvious is going on.
> > b) It is a public library/interface and comments are needed for
> > documentation.
> "useless" for whom? I know many comments that could be removed without any
> doubt. But I also saw many comments that were helpfull for me to understand
> the code quicker and this was not only in really difficult situations. What
> might be useless for you can of course be usefull for others. Have mercy
> with people not as skilled as you.
> Why should a non public libray/interface not get commented? Because it is
> internal and what is internal is only for people who do not need comments?
> > 5. We should limit the amount of plugins/language parts in kdevelop's
> > svn to only those that are best of breed and meet our new mission
> > statement. This means broken/buggy or unmaintained plugins should be
> > removed from svn. I think the only language parts that should go in
> > kdevelop's svn are ones that enjoy wide usage among KDE developers.
> Why only KDE developers? I guess there are also people out there who do not
> develop for KDE with KDevelop. So the basic question is what is widely used
> from KDevelop. I have no idea how this question could be answered. But
> thinking only about KDE seems a bit shortsighted to me.
I agree with Jen's pragmatic replies. In the real world, programmers tend to
layout code according to their own taste, and there is no one right way to
write code. As a professional programmer doing unpaid work on KDevelop, I
certainly don't appreciate being told how to write comments and layout code.
I didn't find any of the code the I've maintained in KDevelop particularly
hard to follow.
A good name for KDevelop4 might be KDevelop4. Calling KDevelop3 'gideon'
wasn't a particularly good idea in my opinion. I have no idea why we need a
'Mission Statement' to give ourselves a sense of direction. We can carry on
subjecting changes to peer review in the usual way for a KDE project. We're
more in need of more people 'doing stuff', than mission statements.
More information about the KDevelop-devel