Your Commenting Style

Started by
15 comments, last by OctDev 21 years ago
I comment a lot, but mainly because I''m a beginner and I don''t want to forget why I coded something in six months time

I have descriptive class and function headers, but my file headers tend to be short and sweet. Also, I plan a lot of my functions in pseudo code first, then as I fill them out the pseudo code becomes the comments.



pan narrans | My Website | Study + Hard Work + Loud Profanity = Good Code
Minister of Propaganda : leighstringer.com : Nobody likes the man who brings bad news - Sophocles (496 BC - 406 BC), Antigone
Advertisement
I don''t comment my code at all (well, once in a rare while I will, but usually comments are code that is temporarily removed).

So far, I''ve only had a single problem understanding my code and that was after almost a year away from it. If I had spent more time on the code, I could have made it more clear, but I wanted to get it done fast at the time so I threw in some hacks to add functionality. Now I don''t feel like rewriting it so I just spent about an hour figuring it out and adding a couple of lines of comments.

I agree with whoever said that if you need a lot of comments you are coding incorrectly. Class names, function names, and variable names should be descriptive enough to give the gist of what the code is doing. If you are using strange algorithms that aren''t easily understood, it would probably be better to include a reference to a document describing the algorithm.
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
quote:Original post by Extrarius
...if you need a lot of comments you are coding incorrectly...

Surely there is a difference between relying on comments, and including them for the purposes of clarity (as a beginner, for potential employers, and for colleagues)?

pan narrans | My Website | Study + Hard Work + Loud Profanity = Good Code
Minister of Propaganda : leighstringer.com : Nobody likes the man who brings bad news - Sophocles (496 BC - 406 BC), Antigone
quote:Original post by Extrarius
I don''t comment my code at all (well, once in a rare while I will, but usually comments are code that is temporarily removed).

So far, I''ve only had a single problem understanding my code and that was after almost a year away from it. If I had spent more time on the code, I could have made it more clear, but I wanted to get it done fast at the time so I threw in some hacks to add functionality. Now I don''t feel like rewriting it so I just spent about an hour figuring it out and adding a couple of lines of comments.

I agree with whoever said that if you need a lot of comments you are coding incorrectly. Class names, function names, and variable names should be descriptive enough to give the gist of what the code is doing. If you are using strange algorithms that aren''t easily understood, it would probably be better to include a reference to a document describing the algorithm.




The entire point of adding in comments to your code is to provide yourself and others with a refrence as to what your train of thought was at the specific time you wrote it. I can gaurentee 3 or 4 years from now if you look at the code you wrote today you''ll either think to yourself "What the hell was I thinking?" or "What does this do?".

Onto some other things....

Functions deserve their own comments for a number of reasons. First and foremost you may have an overloaded function how does this function differ from the other function? Why was it created? What does it do? And why should I use it instead of the other overloaded function? All these questions could be answered with a note under the function comments section, instead of forcing you to read through the functions themselves to see the differences. Also function comments can typically be seen through intellisence in visual C++ which allows you to view these notes with out having to actually goto the function itself, saving you time.

As for class names...
Again because of the possability that someone may choose the same class name as you have you should give a little description of what your class is/does and which headers/libraries are needed for it to compile correctly. This is obviously not to much to ask.

Typically variable names don''t need any specific comments. Unless of course your using names like "foo" and "bar". The need for comments on variables can be reduced dramatically with the use of some derrivitatve of hungarian notation.

Commenting isn''t a sign of "bad programming" it''s a sign of good programming practice. If you comment alot you can always remove un-needed coments at a later time. But if you don''t comment at all eventually you may end up either re-writing the entire peice of code, or having to go through the code & decypher what you once wrote and have long since forgotten.
quote:Original post by pan narrans
[...]
Surely there is a difference between relying on comments, and including them for the purposes of clarity (as a beginner, for potential employers, and for colleagues)?
Sure, but I think having 'function headers'(or class headers, header file headers, etc) is WAY too much commenting in my opinion. The name of a function, the names of its arguments, and a single line comment should be enough to make its purpose(and what it does, and probably even its side effects in most cases) clear.

Of course, if you are programming on a team, you'll need more comments than if you were the sole programmer, but I still think huge headers are too much. If you can't describe the function in 1-2 lines you are probably putting too much in the descripting. I've seen several files in open-source projects where the header details the algorithm used, the specific tricks used in the implementation, etc. All it needed to do was say what the result of calling the function is (like I said, put a link to a document on the algorithm, or put those comments inside the function on a section by section basis) because the caller of a function usually doesn't need to know how it works. Especially when using OO principles, classes and functions can (and usually should) be black boxes. Abstracting implementation from interface is (almost) always a good thing.

[edited by - Extrarius on March 24, 2003 12:32:47 PM]
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
quote:Original post by Extrarius
Sure, but I think having ''function headers''(or class headers, header file headers, etc) is WAY too much commenting in my opinion. The name of a function, the names of its arguments, and a single line comment should be enough to make its purpose(and what it does, and probably even its side effects in most cases) clear.

Of course, if you are programming on a team, you''ll need more comments than if you were the sole programmer, but I still think huge headers are too much. If you can''t describe the function in 1-2 lines you are probably putting too much in the descripting. I''ve seen several files in open-source projects where the header details the algorithm used, the specific tricks used in the implementation, etc. All it needed to do was say what the result of calling the function is (like I said, put a link to a document on the algorithm, or put those comments inside the function on a section by section basis) because the caller of a function usually doesn''t need to know how it works. Especially when using OO principles, classes and functions can (and usually should) be black boxes. Abstracting implementation from interface is (almost) always a good thing.

<SPAN CLASS=editedby>[edited by - Extrarius on March 24, 2003 12:32:47 PM]</SPAN>


Yes when using OO Principles thing should be a black box for the user however this black box theory should not be applied to those who are maintaining and updating the black box code itself.

Huge "file headers" are used to track the changes that have been made to the file. The dates that they were changed, and the user who had changed them. Granted you can remove this a tad by using some type of source control but it still serves a purpose.
Well, when maintaining your Camera class, for ex, you shouldn''t need to know which engine you are using etc. You just need to know that the camera class sets up a matrix based on its inputs and sends the matrix to the renderer. In this sense, everything but the class you are maintaining is a black box to even you. Unless you are debugging inter-class communication, you shouldn''t need to know how the other classes work. There are of course exceptions, but in general that is how I think it should be.

Those few comments I said I use are usually things like implementation specific tricks of an algorithm, because those are the places hardest to understand (as they are often ''hacks'' to improve performance, they might not follow the algorithm in an obvious manner). If I used a bit field instead a closed list in A*, I might put a comment where the bitfield is defined, but it would be something like ''bitfield instead of closed list to track already visited nodes'' at most (more probably ''bitfield for closed list''). If you know the algorithm being implemented, it should generally be easy to understand the implementation if there are such comments (if I were commenting for somebody else, I might put a comment at the start of each step, like ''choose cheapest node in open list'')
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk

This topic is closed to new replies.

Advertisement