[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    Re: Direction of KDevelop4
From:       Cavalaria Christophe <chris.cavalaria () free ! fr>
Date:       2005-09-13 22:54:33
Message-ID: 200509140054.37953.chris.cavalaria () free ! fr
[Download RAW message or body]

On Monday 12 September 2005 21:45, Andrew Sutton wrote:
> > As I've said, I only want useless comments thrown out.  I specifically
> > exempted from my wish list those that document subtle problems.
>
> normally, i wouldn't bother contributing my $.02 to the discussion
> because i'm not a kdevelop developer, but i thought i might weigh in
> on this topic because commenting style comes up alot in my lab (we
> all teach or have taught programming). the only useless comments are
> those that are inconsistent with what the code actually does.
> otherwise, comments, among other things, serve to document
> information that just can't be written down in the syntax of the
> language (e.g., rationale). for me they often serve as reminders for
> what i'm doing and why. so while i may have written functions that
> are over 60% comment, but you know what? anybody who looks at it can
> tell exactly what they do and why they do it that way.

On the other hand, the more comments there is, the easier it is to have them 
go out of synch with the code. And as you say, the only real bad comment is a 
lying comment.

> anyway, there are two points to make. first, standardizing commenting
> style (how much and where) is a complete waste of time. second,
> _removing_ comments is just asinine. if you didn't write the code
> originally, how do you know what comments are useful to its writer. i
> would actually be supremely pissed if somebody went ahead and deleted
> comments out of my code. it's just plain rude.
>
> that said, i try to teach my students to comment so i can look at a
> piece of code they write and understand the logic of what they're
> trying to do. it helps me figure out why they're might be trying to
> write a program one way as opposed to another, or if there are any
> obvious flaws in the logic. but that's how i roll.

Wouldn't it be a great test to ask them to write a program without a single 
comment and remind them that you will have to understand what they wrote very 
easily ? That way, you would theach them not to write obfuscated code, even 
if there is some comment to explain what it does.

[Attachment #3 (application/pgp-signature)]
_______________________________________________
KDevelop-devel mailing list
KDevelop-devel@barney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel

[prev in list] [next in list] [prev in thread] [next in thread]