KDE/kdevplatform/debugger

[Andreas Pakulat]

On 21.07.09 21:22:14, Amilcar do Carmo Lucas wrote:
> On Tuesday 21 July 2009 07:21:45 Andreas Pakulat wrote:
> > > -#include <KTextEditor/Document>
> > > -#include <KTextEditor/View>
> > > +#include <KDE/KTextEditor/Document>
> > > +#include <KDE/KTextEditor/View>
> >
> > @Amilcar: This is bogus, the KDE directory is added by cmake, if that
> > doesn't work for you please complain to SuSE.
> 
> No, openSUSE works fine without it.
> 
> But krazy complains about it. As you may have noticed I only do krazy commits 
> to kdevplatform, because that one actually has an API that should be clean, 
> consistent and documented. KDevelop has no API, so I do not do commits there.

Then apparently krazy has a bug. There's no policy saying that we should
a) use mixed-case headers over lower-case headers
b) need the KDE/ prefix

Nor could I find any info about this on the ebn as krazy is apparently
broken right now.

> That is why I feel that the automated krazy tests are of great help. Nobody 
> has the time to manually verify the quality and consistency of the code, but 
> doing it automatically has a cost of zero and is _consistent_. The same set of 
> rules are used for all files.

Blindly applying the warnings from krazy is complete and utter nonsense.
The changes that krazy suggests need to be reviewed before being comitted.
And so far, the krazy fixes you applied don't help improving our API at
all.

> I know that you and David do not like krazy. But I hope that the explanation 
> above makes it clear why I like it.

Its not that I don't like krazy, its a really good tool to find the
easy-to-overlook things. However the changes it suggests need to be
reviewed and in particular changes on the API of functions or existing code
need to be thought about very thorougly as the commit will affect the svn
history and makes it harder to find out why a certain piece of code has
been written as it is.

krazy is in no way the "wholy grail" to make an API better or even
consistent and I think I'd like to ask you to stop fixing "code issues"
reported by krazy unless they got reviewed and they get a proper
commit-message that explains what is being improved and why (or at least
points to a website that explains this that doesn't vanish on the next
krazy-run)

Its IMHO far more important to make some progress on the API docs of our
public API, then fixing some #include's.

Andreas

-- 
You like to form new friendships and make new acquaintances.