Direction of KDevelop4

[Adam Treat]

On Monday September 12 2005 9:58 am, Vladimir Prus wrote:
> > Look, I specifically said all unobvious code should be commented. 
> > However, this should be very rare.  If code is so confusing as to need
> > this, then it is either not very good, hacky, or not very well thought
> > out and should be refactored.
>
> I disagree.  As I said, often the code is clear, but the motivation of the
> code is not. Say, this code in gdb reply processing:
>
>     QCString r(buf);
>     r.replace( QRegExp("\\\\000|\\\\0"), "" );
>
> is absolutely clear, but why it's there. The answer (producing reasonable
> result for QString), is not at all obvious, and requires comment. There's
> no problem with the code, but comment is needed. I see many such cases.

Yah, well, commenting it with "produce reasonable result for QString" is just 
the type of useless comment I'm talking about.  It explains nothing and just 
takes up space ;)

>
> The kinds of comments I most interested in do not duplicate the code. They
> explain external context/motivation for the code.
>

Good code should be understood by just reading it.  No, I'm not talking about 
complex RegExp.

> > Have a look at:
> > http://websvn.kde.org/trunk/KDE/kdevelop/src/partcontroller.cpp?rev=45424
> >5& view=auto
> > http://websvn.kde.org/trunk/KDE/kdevelop/src/main.cpp?rev=454225&view=aut
> >o
> > http://websvn.kde.org/trunk/KDE/kdevelop/src/projectmanager.cpp?rev=45422
> >5& view=auto countless others...
>
> Had a look. Except for mixing different indent depths (tabs count as mixing
> indent depths), there's nothing is those files that really slows me down.

Damn, I don't ever want to bugfix after you ;)  Seriously, those files have 
inconsistent styles from method to method, and in some cases, in the very 
same method.  We have:

if(something) {
}

for ( blah )
{
}

while ( foo ) {
}

etc, etc.

But, now I know if I'm ever bugfixing your code I'll just write:

if(something){blah blah blah;}for ( blah ){ blah blah blah; }while ( foo ) 
{blah }

...since you don't give a crap.

> Your own, I guess. Again, there should be specific base indent offset, so
> that you clearly know which nesting level you're at, but everything else is
> a personal choice.

> > Second, because
> > this makes my eyes bleed.
>
> Well, that's very subjective.

Thanks.  So, since it is my personal choice and so subjective and all, I'll be 
sure to modify your files with code obfuscated so bad that you'll be begging 
for some perl. Of course, I'll make sure to comment the hell out of it to 
keep you happy.

> > Source code should be beautiful and self explanatory in the vast majority
> > of the cases.  If it is not, then usually it needs to be refactored,
> > cleaned up and given a common coding style.
>
> I doubt that code can be self explanatory without comments. I'd go as far
> as saying that every method (even in internal headers), should document: 1.
> What it does
> 2. (for slots) when it's supposed to be called
> 3. (for signals) when it's supposed to be emitted

Well, given the above, I can see why you doubt source can be self explanatory.

-- 
I'm running a Marathon in December!
HELP ME SAVE LIVES and Donate Today!
http://helpmesavelives.blogspot.com/