Code comments: How do you comment your code?

[Lost User]

Join the cool kids - Come fold with us[^]

[Dalek Dave]

hmm, let me just try th

------------------------------------ No Good Deed Goes Unpunished Clare Boothe Luce

[Ravi Bhavnani]

I've been using a simple yet effective rule for writing comments for decades:

• Remove all code except for block boundaries (i.e. everything except stuff in conditional expressions and opening and closing curly braces).
• Do the remaining comments and "code shell" represent the psuedocode fairly accurately?
• If yes, you're done. Else, you need more comments.

It's amazing how well this rule works.  Without conciously trying, applying this rule caused me to move from writing few long-winded PhD thesis comment blocks to several small one-line phrases that increase readability many fold. /ravi

My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com

[Single Step Debugger]

I don’t comment my code, even the most complex parts. Nobody pays me for comments, they want functionality and reliability. What?

The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.

[realJSOP]

I do it mainly for myself so that I can remember the whats-and-whys more than anything else, and to provide a foundation of knowledge regarding the system, and the reasons for its existence.

.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001

[Dalek Dave]

And you want to keep the contract, right?

------------------------------------ No Good Deed Goes Unpunished Clare Boothe Luce

[dan sh]

John Simmons / outlaw programmer wrote:

I write a separate "How It Works" document in Word

Cool! I also maintain a notepad file (just for myself) containing why I wrote the code block that way. I also try to maintain what I had tried and why it failed so that I don't end up doing same thing again.

50-50-90 rule: Anytime I have a 50-50 chance of getting something right, there's a 90% probability I'll get it wrong...!!

[Single Step Debugger]

Dalek Dave wrote:

And you want to keep the contract, right?

I definitely do, but this doesn’t involve losing hours and hours in writing useless comments.

/*
* This function returns the next document in the sequence!
*This is an extremely useful comment! It makes me feel real professional!
*My Mother will be real proud with me! And I’m going to use an automates toll to generate an utterly
*useless documentation for this application.
*
*/
LPDISPATCH CDocumentation::GetTheNextDocumentWithPreview()
{
iDispatch->GetNextDocument(true);
}

The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.

[Mark_Wallace]

Trollslayer wrote:

CalcNumber firstNumber = CalcNumber.create(3);
CalcNumber secondNumber = CalcNumber.create(2);
CalcNumber nutting = CalcNumber.create(0);

figureToPost = firstNumber + secondNumber;
figureToPost += nutting;

returnString = figureToPost.ToString();
fullPoint = ".";

String.Concat(returnString, fullPoint);

return returnString;

See? Works every time! Your pseudocode helped me construct it easily!

I wanna be a eunuchs developer! Pass me a bread knife!

[Daniel Grunwald]

I comment the public API of my classes using XML documentation comments. Though often it's obvious what a method is doing given its name, so I only fill in a short summary and leave out the parameters/return value stuff. I do use regions to group methods in large classes. I think it's a sign that the class is too large, but that's unavoidable in some frameworks (e.g. when writing WPF controls). For the implementation inside methods, I usually don't write any comments initially. If I have to change the code to fix bugs, I'll add comments why the fix was necessary (unless the bug was just some kind of typo). Basically, you shouldn't need comments to see what the code is doing. Inline comments should explain why the code is doing it, but only if that isn't obvious given the method's name/documentation. I also make use heavy use of invariants, so my Debug.Assert statements can be seen as a kind of comment.

[Joe Woodbury]

I rarely do. I've found comments are pretty useless and mostly good for giving people warm and fuzzies. Instead, I use very descriptive names for functions, methods, classes and variables and keep my code as simple as possible. Same with my coworkers.

Harvey Saayman wrote:

(usually explaining why your in a specific part of an if statement)

See, that's idiotic. If your "if" statement is written so poorly that you don't know why you're in it, your programming technique sucks. Some code I just wrote:

...
} while (m_curSelection != orgSelection && !m_pItems[m_curSelection].IsSelectable());

No comment is going to make that more clear.

[Marc Clifton]

Harvey Saayman wrote:

I've decided to make use of regions

I despise regions!

Harvey Saayman wrote:

So how do you comment your code?

Don't tell me what the code does (I can figure that out quickly enough) tell me WHY it does it, and what the decisions were to lead up to that implementation. That brings a lot more understanding, IMO. Marc

Will work for food. Interacx

I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner

[Gary Wheeler]

Marc Clifton wrote:

I despise regions!

Unfortunately, I think most people think of regions as a documentation mechanism, rather than an editing tool. I use them to make the outlining more useful. With regions, I can more quickly collapse parts of the code out of the way so I can concentrate on the other bits.

Software Zen: delete this;

[Ennis Ray Lynch Jr]

I hate regions. Ironically, the C++ TCP server I wrote doesn't have any comments while most of my code is usually extensively, logically commented.

Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane

[N a v a n e e t h]

I too hate regions.

Harvey Saayman wrote:

So how do you comment your code?

I hardly write comments because it is very hard to keep it updated when you change the code. IMO, most of the programmers can easily read code without the help of comments. All you need to ensure is the code is well written by using meaningful method and class names. :)

Best wishes, Navaneeth

[Marc Clifton]

Gary Wheeler wrote:

With regions, I can more quickly collapse parts of the code out of the way so I can concentrate on the other bits.

My "region" limit is files. If the code is getting so big in a particular class (let's assume here that there's one class per file) then it can be broken up into separate files, even with the same class, or perhaps the class design should be looked at. I don't like regions around fields, properties, events, etc., because mostly I'm not even looking at those anyways. But happily, I can set the editor to not collapse regions for those that do like regions, so I'm happy. :) Marc

Will work for food. Interacx

I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner

[Single Step Debugger]

N a v a n e e t h wrote:

I hardly write comments because it is very hard to keep it updated when you change the code. IMO, most of the programmers can easily read code without the help of comments. All you need to ensure is the code is well written by using meaningful method and class names.

Quoted and fived! :)

The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.

[Roger Wright]

Since I tend to get interrupted or distracted while working on a project, it often gets set aside for weeks at a time. I often forget what I was planning to do next, so I've adopted the practice of commenting the crap out of everything I do. Even before I start, out of long habit, I write a skeleton program (these days the IDE does that for me), then block it out with comments before I start writing any code. Those comments usually include any pseudocode I can think of to document my thoughts about how to build each section. When I'm done, I sometimes remove the unnecessary comments, and sometimes I don't. Since no one else ever sees it, what does it matter if I leave it cluttered by my notes? :-D

"A Journey of a Thousand Rest Stops Begins with a Single Movement"