Direction of KDevelop4
treat at kde.org
Mon Sep 12 15:33:02 UTC 2005
On Monday September 12 2005 9:08 am, Vladimir Prus wrote:
> FWIW, when getting hold of debugger code, I really wished it has much more
> comments! There were a lot of code which function was obvious, but it's was
> not clear why the code is needed, and how it fits in the overall picture.
> Generally, I never seen a piece of software with too much comments, so we
> should strive for more comments, not less.
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
There are simply way to many places where I have to wade through uninstalled
header files which begin with "//this is a header file for the foobar class"
or .cpp files with "//this is the implementation for foobar class" or methods
which begin "//this method takes an int and bool and returns a QString"
Absolutely unexcuseable and unnecessary.
I like to read code to figure out what is going on. Reading others comments,
although sometimes needed for particularly subtle problems, slows me down.
Often, the comment is superfluous and could just as easily be understood by
looking at the method/class or I'm browsing through source code and can't see
the damn source for all the glaring comments everywhere.
> > 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...
> Again, FWIW, except for basic indent (2 or 4), I don't see any effect of
> coding style on readability.
Have a look at:
I count at least a few different coding styles in the _same_ file. Some
places I see tab indent. Some places I see space indent. Some places I see
brackets on the same line and some I see brackets on the next line. Some
methods calls have spacing around the arguments, some don't. This is
unacceptable. First, because if I want to modify or add to this file, I
can't determine what is the correct coding style to use. Second, because
this makes my eyes bleed.
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'm running a Marathon in December!
HELP ME SAVE LIVES and Donate Today!
More information about the KDevelop-devel