just a general question
Is it me or do a lot of new programer not comment their programs? Just asking cause when i was doing this in college in the early 90 that was beaten into me to do.
The issue is that knowing what to comment and why is not a trivial or agreed-upon thing. Like with formatting, commenting is something that everyone has their own opinion on. Unlike formatting, commenting is a much more complex thing to do - how would you explain the difference between bad comments ("calls the function") and good comments (???)?
Yes, I forgot to mention there are some schools of thought which say that if you have to write a comment to explain something, it means the code is written poorly, and therefore good code should require no comments. I only partially agree with this.
true but as a new programer learning what i am doing comments do help. It is easier to pull back after you start learn when and were to comment. As A new programer some time i write code then have to log (as i ma doing this while on chemo so lot of bathroom runs) and i forgot what i was think about when i log back on.
Comments should be useful to everyone who will read your code. If you are the only person who will ever read your code, then you can comment as you like, but if you want others to read your code, notes to self are not useful.
EDIT: This post has been reported, clearly I am not wanted in this thread.
EDIT: This post has been reported, clearly I am not wanted in this thread.
Last edited on
| As A new programer some time i write code then have to log (as i ma doing this while on chemo so lot of bathroom runs) and i forgot what i was think about when i log back on. |
This is a total noob question, but.......
......when the compiler compiles the .exe, the comments are disgarded, right? So having copious amounts of comments doesn't make your .exe any bigger?
......when the compiler compiles the .exe, the comments are disgarded, right? So having copious amounts of comments doesn't make your .exe any bigger?
Yes, in fact the comments are usually discarded by the preprocessor before the compiler even sees the code.
EDIT: This post has been reported, clearly I am not wanted in this thread.
EDIT: This post has been reported, clearly I am not wanted in this thread.
Last edited on
yep Lb is right.. comments just help when someone come back and has to read your code. Or, even your self after you have not see it in a bit.
Proper commenting is somewhat like proper formatting - a matter largely ignored by many beginners, but often regarded as vital by veteran programmers.
There are various reasons for this difference in perspective.
For instance, both practices (commenting and formatting) can result in code which is easier to understand, maintain, re-use, etc. But a beginner probably isn't working with other programmers on a given project, and so may not see much value in having others more easily understand his code. He may also be writing relatively simple programs, where the source code is readily understood even without copious comments and consistent formatting.
Additionally, to the beginning programmer, simply writing code which runs is often a great enough challenge. For him, "Does it run?" is the sine quo non of success. He's less likely to care overmuch about programming niceties which go beyond this benchmark.
Moreover, I suspect that many beginners don't understand how best to comment code. I would venture to suggest that all too many beginners first write their code, then devote considerable time to editing, revising, and generally debugging it, and only then - as something of a final step - do they go back and make some cursory effort at commenting it.
This is typically a terrible way to comment code (albeit, better than not commenting it at all). More experienced programmers seem to understand this fact, and they will write comments more-or-less as they write their code - a much more sensible approach.
All this having been said, I'd note that many computer programming instructors at the high school and university level do make it clear in their class syllabi that a student will have points deducted from his grade for submitting an assignment which - while it may run - fails to adhere to some course-mandated commenting and formatting standard. Just as in other, non-programming classes a paper may be marked down by several points for errors in spelling, grammar, punctuation, footnoting, structure, voice, length, etc. (Content is vital, but form and presentation matter, too.)
(Various generalities in the above, and obviously many exceptions exist.)
There are various reasons for this difference in perspective.
For instance, both practices (commenting and formatting) can result in code which is easier to understand, maintain, re-use, etc. But a beginner probably isn't working with other programmers on a given project, and so may not see much value in having others more easily understand his code. He may also be writing relatively simple programs, where the source code is readily understood even without copious comments and consistent formatting.
Additionally, to the beginning programmer, simply writing code which runs is often a great enough challenge. For him, "Does it run?" is the sine quo non of success. He's less likely to care overmuch about programming niceties which go beyond this benchmark.
Moreover, I suspect that many beginners don't understand how best to comment code. I would venture to suggest that all too many beginners first write their code, then devote considerable time to editing, revising, and generally debugging it, and only then - as something of a final step - do they go back and make some cursory effort at commenting it.
This is typically a terrible way to comment code (albeit, better than not commenting it at all). More experienced programmers seem to understand this fact, and they will write comments more-or-less as they write their code - a much more sensible approach.
All this having been said, I'd note that many computer programming instructors at the high school and university level do make it clear in their class syllabi that a student will have points deducted from his grade for submitting an assignment which - while it may run - fails to adhere to some course-mandated commenting and formatting standard. Just as in other, non-programming classes a paper may be marked down by several points for errors in spelling, grammar, punctuation, footnoting, structure, voice, length, etc. (Content is vital, but form and presentation matter, too.)
(Various generalities in the above, and obviously many exceptions exist.)
It there any place to get info on what is good commenting. As i like to comment as i work on stuff so i dot have to relearn it later?
I often start with comments that give pseudocode for what I want to do. Then I fill in with the actual code. This tends to make the code really easy to follow later on.
Code itself generally says what it does. The comments should say why you're doing it and sometimes how. If you look at it this way, then it's clear that self-documenting code is nearly impossible: the code doesn't say why it's doing something. More importantly, the code doesn't say what you're trying to do, only what you're actually doing. Good comments can help locate bugs in code later on.
It's very important to comment your functions and methods, especially any restrictions on the parameters or return values. If you return a pointer then who owns the data that it points to? How long is it valid? What are the error conditions?
For beginners doing assignments, I'd recommend adding a comment that includes the assignment itself or a pointer to it. 2 years later when you're trying to review some old code as a refresher for a new course, you may want to know what the heck the program is all about.
The comments will different for the (potential) audience too. A professional might comment 50 line with "breadth first search to maximize coverage." Another professional in the same field would understand this. On the other hand, a beginner coding a breadth-first search algorithm is likely to need lots of comments on the specifics of the algorithm.
Code itself generally says what it does. The comments should say why you're doing it and sometimes how. If you look at it this way, then it's clear that self-documenting code is nearly impossible: the code doesn't say why it's doing something. More importantly, the code doesn't say what you're trying to do, only what you're actually doing. Good comments can help locate bugs in code later on.
It's very important to comment your functions and methods, especially any restrictions on the parameters or return values. If you return a pointer then who owns the data that it points to? How long is it valid? What are the error conditions?
For beginners doing assignments, I'd recommend adding a comment that includes the assignment itself or a pointer to it. 2 years later when you're trying to review some old code as a refresher for a new course, you may want to know what the heck the program is all about.
The comments will different for the (potential) audience too. A professional might comment 50 line with "breadth first search to maximize coverage." Another professional in the same field would understand this. On the other hand, a beginner coding a breadth-first search algorithm is likely to need lots of comments on the specifics of the algorithm.
Topic archived. No new replies allowed.