Commentaries - above or below the code?
-
A programmingcommenting question. I have been writing commentaries above a related line of code, like this:
// The Init() method we call here initializes an array of points
Init();However, I have seen a big sample of code written by one of my professors recently. The commentaries was placed below a line.
Init();
// The Init() method we call here initializes an array of pointsSincerely, I have found it very clear and understable. Did anybody encounter such approach to commenting code? Is it recommended?
Greetings - Jacek
I always defer to my favorite software book Code Complete for these kinds of questions. McConnell spends a whole chapter talking about best practices in writing comments. (This may seem silly to some, but if you read the book, it makes a TON of sense.) Chapter 32 states plainly "Use comments to prepare the reader for what is to follow", and explains the well-established convention of putting comments above the code it's documenting. Further (and this is the fun part you can show your professor), he claims "This idea isn't always taught in programming classes, but it's a well-established convention in commercial practice." Well-established conventions, until there is a clear technical reason to do otherwise, should be followed! Also, there has been some discussion hinting that well-crafted code should not need comments. My thought is all about how fast you can look at code to quickly understand what it's supposed to do. Your brain doesn't waste time translating variable names (even if they're well named), doing math, finding control loop conditions, etc. Stuart
-
A programmingcommenting question. I have been writing commentaries above a related line of code, like this:
// The Init() method we call here initializes an array of points
Init();However, I have seen a big sample of code written by one of my professors recently. The commentaries was placed below a line.
Init();
// The Init() method we call here initializes an array of pointsSincerely, I have found it very clear and understable. Did anybody encounter such approach to commenting code? Is it recommended?
Greetings - Jacek
A couple of lines for general explanation above the code block, and short 2 or 3 word comments at the end of appropriate lines to explain what a particular variable or called function is for. Always worked for me.
-
A programmingcommenting question. I have been writing commentaries above a related line of code, like this:
// The Init() method we call here initializes an array of points
Init();However, I have seen a big sample of code written by one of my professors recently. The commentaries was placed below a line.
Init();
// The Init() method we call here initializes an array of pointsSincerely, I have found it very clear and understable. Did anybody encounter such approach to commenting code? Is it recommended?
Greetings - Jacek
Personally, my comments generally come before the code, but it's because of the way I code. I don't set out to write comments; rather, as I enter a new conceptual block, I find that it helps clear my mind to write a quick explanation of what I'm going to do. Then I find it easier to focus on what needs to be done within the conceptual block. Thus, the comments I write actually direct the code, rather than the other way around. I don't need to go back over the code and add comments this way. Basically, if there's a comment in the code, it's because it was needed to write the code; if there's not, it's because the conceptual block was straight-forward enough that this guide wasn't necessary for my initial thoughts. I suppose you could say my coding style is self-commenting. Or is my commenting style self-coding? :)
-
Or even better, rename the function so you don't need the comment.
That's right. The old 'self documenting code' joke is not always a joke. Take time and space to make variable names mean something. Make the method name be really indicative of what it does. I use long, descriptive variable and method names, and my experience is that they are more likely to stay up to date than the comments are, and less likely to be re-used in an inappropriate manner. 'int i;' will get used/reused on demand, but 'int windowIdx; will generally only be used for the index of a window, into a list of windows. But comments are required where the code can not be made easy to understand, because it is actually very complex algorithm, it has been optimized, or for some other reason obfuscated.
Silver member by constant and unflinching longevity.
-
Comments below the line of code? Sure, if you're the sort of person who wears their underpants on top of their trousers.
"People who don't like their beliefs being laughed at shouldn't have such funny beliefs." ~ Anon "If you can't explain it simply, you don't understand it well enough" ~ Albert Einstein Currently reading: 'The Greatest Show on Earth', by Richard Dawkins.
-
"You botched it", basically, for different values of "it".
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server -
As almost everyone has replied previously, generally comments appear above the code or inline. In the world of academia, where real-world applications, programming teams and programmers are sparse to non-existent, you may find lots of things that are different to what really goes out in the real-world. That being said, although I may be wrong, there is one time when I will put a comment after the line of code, and that is in the case of 'else'.
// This explains what will happen when 'condition' is true
if( true )
{
...
}
else
{
// This explains what happens in other cases
}I'm not sure what others do in this case, but then again, it is very specific, only appears inside a function block, and is pretty clear when reading the code.
-
Everyone, for ever, has placed it above. Let's just stick to the accepted pattern and move along.
cheers, Chris Maunder The Code Project Co-founder Microsoft C++ MVP
-
I agree with the consensus, above. It is easier to read, and tells you what to expect.
------------------------------------ In science, 'fact' can only mean 'confirmed to such a degree that it would be perverse to withhold provisional assent.' I suppose that apples might start to rise tomorrow, but the possibility does not merit equal time in physics classrooms. Stephen J Gould
-
A programmingcommenting question. I have been writing commentaries above a related line of code, like this:
// The Init() method we call here initializes an array of points
Init();However, I have seen a big sample of code written by one of my professors recently. The commentaries was placed below a line.
Init();
// The Init() method we call here initializes an array of pointsSincerely, I have found it very clear and understable. Did anybody encounter such approach to commenting code? Is it recommended?
Greetings - Jacek
Above the code that implements it is best. That allows the reader to go from generalitites to specifics by reading top to bottom, just like an outline, or a story, or any other type of explanatory writing. I think you should your the entire class to turn in an assignment with the comments below the code they comment. They can't mark down for it since the professor provides examples comemnted that way. If they actually read your source code, they'll probably try to mark it down though.
patbob