Re: Comments
From: Graham Stratford (gstratford_at_das.ca)
Date: 06/24/04
- Next message: Kristofer Skaug: "Re: Comments"
- Previous message: Will DeWitt Jr.: "Re: Delphi 8 vs Visual Studio"
- In reply to: Kristofer Skaug: "Re: Comments"
- Next in thread: Loren Pechtel: "Re: Comments"
- Reply: Loren Pechtel: "Re: Comments"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 24 Jun 2004 09:46:29 -0400
I have a couple of rules that I follow:
Comments should not show "what" a section of code is doing (unless it is
rather complex), but "why" it is doing so. Of course, there is always a
place for comments at the head of units, functions, etc.
Also, every time I put in a comment, I try to think whether the code
wouldn't be better served with a function/procedure that accomplishes
the same goal. For example:
// Check to see if the user has permission
... my code here ...
might be easier to understand and maintain if it were put into a
function called
function TMyObject.CheckUserPermission();
Graham
In article <40d955fd$1@newsgroups.borland.com>, ya.ierfgnf@thnxf.x
says...
> Scout wrote:
> >
> > What rules do you use in deciding what (and what not) to comment?
> Myself I tend to comment rather more than less, when in doubt. I have too
> many times noticed that "simple, obvious" things (to me) are far from
> obvious to a colleague who has to jump in and fix something in my code.
> Of course I don't mean stupid things like "inc(i); // increase i by one"
> type comments; but rather the goings-on at application levels higher than
> that - there's plenty of medium-to-high-level stuff that warrants an
> explanation.
- Next message: Kristofer Skaug: "Re: Comments"
- Previous message: Will DeWitt Jr.: "Re: Delphi 8 vs Visual Studio"
- In reply to: Kristofer Skaug: "Re: Comments"
- Next in thread: Loren Pechtel: "Re: Comments"
- Reply: Loren Pechtel: "Re: Comments"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
