Direction of KDevelop4

[Richard Dale]

On Monday 12 September 2005 19:22, Jens Herden wrote:
> Hi,
>
> > 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.

-- Richard