|
I use comments mostly to remind future me that this needed to be done this way because ...
and then future me tells me that that's no longer the case - these days we have something called new buzzword ...
So we sort of complement each other.
25+ years for the same employer -- and some of those products (from even further back in time) are still with us ... Some unfortunately, some rightly so.
|
|
|
|
|
I never write comments.
As it happens, I just hired a junior and he loves comments.
He writes all sorts of useless comments like // set the variable.
I told him not to do that because we can read code.
Point is, he doesn't read code that well yet and the comments help him see what happens.
He also writes comments like // why does this work?
So he'll be reminded to ask me.
One time we rearranged some code and all of his comments had to moved and/or changed as well.
People sometimes forget that comments are just like code, they're hard to write well and they need maintainance just like code.
Comment maintainance is rare and so most of the time comments are just as unclear as the code, outdated or even plain wrong.
I rarely trust a comment and when I see them I'll try to change the code so they won't be necessary anymore.
That's not to say I never write them.
I once worked with a library (Crystal Reports, 'nuff said) where setting one property would set another one to null.
So the order in which I set specific properties had to be very specific too.
Needless to say I wrote a comment saying // do not switch these lines around, the person who wrote this library was drunk and drugged and the order somehow matters.
|
|
|
|
|
Sander Rossel wrote: I never write comments.
Sander Rossel wrote: That's not to say I never write them.
|
|
|
|
|
Never say never 
I write them like once every few years whenever I find some weird ass third party component I really can't ditch 
|
|
|
|
|
|
His commenting may be providing him with "thinking space" ... the same way some people doodle. I expect he'll outgrow it.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Long back, had inherited a code like this:
bool funcName( five arguments of different types )
{
return true;
}
No comments in the code, rather the entire code was commented out.
Unfortunately, could not get my hand on the coder who created this, he had resigned.
|
|
|
|
|
one of my products is 23 years old now since i launched it (started writing it in the late 90's), written in vb6. I sold over 1000 copies back in the day (and even sold a new one a year ago). I still have quite a few users who pay support (and a few who don't) and dont see the need to change or upgrade to my newer version coz it does everything they want and they are comfortable with it. my newer version was launched 2010 and is a net framework product, so i suppose 13yo for that is getting quite aged these days, but again i have loads of customers on it. I am a compulsive 'commenter' (always have been) since the 70's, even though the code is never likely to be seen by anyone else, and now i'm in my 60's (and still coding), the grey matter aint as sharp as it once was there's a definate advantage when i need to make mods, and imho code that aint documented aint complete. GL
|
|
|
|
|
Yes ... commenting can be seen as an investment in terms of when it comes time to "sell the company". One man's noise is another man's salvation.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
charlieg wrote: Do comments even matter any more, or am I flattering myself?
Comments matter A LOT. Although, going through the previous replies I can see a contrarian trend ("I don't write comments", "code should be self-documenting", etc.). Sorry, but I find it ludicrous, at least in my line of work. Just two days ago I was working on this code:
const double pre_2008[2][14] = {
{ 0.0019, 0.0017, 0.0105, -0.00134, 0.00, 0.00, 0.00,
-0.0001, -0.0001, 0.0018, 0.00008, 0.00, 0.00, 0.00}, { 0.0020, 0.0009, 0.0047, -0.00094, 0.00, 0.00, 0.00, -0.0003, 0.0, 0.0, 0.00, 0.00, 0.00, 0.00}
};
Pray tell me, how would you write this in a self-documenting way? If I wouldn't have put that comment block there, would anyone (myself included) had been able to figure out what's going on?
So, for your own sanity and for the sanity of those around you, please, keep commenting!
Mircea
|
|
|
|
|
My oldest code that I maintain is no more than ~10 years old (have moved companies, products have been EOL'ed, etc.), but I've always been a compulsive commenter. The comments mostly help me, six months down the line.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I find it depends on what language I'm writing in and, to a certain degree, what the code is doing. In general, I'll have more comments when I'm writing C code than I do for C# and Java. I've got some C code that does some quite involved data manipulation. That code has both in-line comments and a notice at the top that says "read and UNDERSTAND the XXX page on the project wiki before you do anything with this code." What it's doing is so complex both high-level and low-level block comments are needed for anyone besides me to modify it. I've also got some C code that does the equivalent of serialization; that code has no comments beyond "save the data via serialization"
As with all things coding --- it depends.
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
I used to write comments all over the place that know one reads, even me.
Nowadays I write comments so GitHub Copilot can generate code off of it auto-magically. 😁
|
|
|
|
|
Absolutely do matter, anyone tells you otherwise does not have 40 years experience.
The concept of "self-documenting" code is nice, sometimes do-able. But the time
it takes to write a comment (or a few comments) for code that is non-trivial is
saved many times over as that code is revisited in coming *decades* (think the
build up to Y2K when we needed to figure out code written between 1965 and 1990).
Not commenting is short-sighted and, I think, selfish and arrogant of the developer
who assumes:
1) later developers are as good as he thinks he is
2) his time is too valuable to be wasted doing non-coding tasks.
Sorry, personal pet peeve of mine picking up process control C code written in the
mid-1990s with zero comments that does not work.
|
|
|
|
|
WPerkins wrote: The concept of "self-documenting" code is nice, sometimes do-able.
"Self-documenting APL code", is than an oxymoron or not?
|
|
|
|
|
Since this seems to be two questions, I'll answer in two parts:
Code comments: I use comments very sparingly, really only when the code is complicated. Yesterday I wrote more comments than I typically write in a month, describing for myself the layout/elements of several multi-dimensional arrays. I do find that I comment more these days that I used to.
How old is my code? My company's flagship product was released to the public at a trade show in the summer of 2K. Since development started around 1.5 years before that, there is code that dates back to '98 when I got hired...so around 25 years ago! 
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
FWIW I read comments others have written.
Even if I'm the only one who will ever read my comments, that makes them worthwhile.
I try very hard to make my comments clear and concise to improve the chances that they will be read.
|
|
|
|
|
Definitely for myself, though most of the comments nowadays seem to be // TODO: fix this bug
|
|
|
|
|
I started programming in the late 70's so the only real option was assembly code for the devices I was programming for. It pretty much cemented the idea that I should be commenting my code. It's a practice that I kept throughout my career. Commenting was for my own benefit and for anyone who might be modifying my code. I always made the assumption that the person inheriting one of my projects wouldn't necessarily be a very knowledgeable programmer so good commenting was needed.
|
|
|
|
|
There has been a fairly recent crusade against comments. Some claim code should be self-documenting and that comments are somehow evil.
You know what's documenting? Documentation... like comments.
Self-documenting? WTF? There's nearly zero code ever written that explains WHY it does what it does or WHY it was changed to do otherwise. I guess you can enforce tying commits to cards and chase down the commit that changed the code and then the card that brought that commit.
Alternatively, maybe a comment isn't such a bad thing.
Has nobody written a VS plugin to just turn all comments on/off?
Is it really just that developers hate documentation so much they'd rather claim their code does all the documentation for them? Because that's just how great their code is?
Do people not use XML comments so people get intellisense on what they are calling? Do they think making that block descriptive is some massive chore?
|
|
|
|
|
That crusade against comments has been going on for many years, where I have been.
The major exception is huge copyright/left comment blocks topping every source file and extensive comment blocks heading every function, repeating the function name, the the types and names of all parameters of the function declaration, only doing it in 10-20 lines instead of one, cluttered with typographic markup.
I have been heavily criticized for my habit of adding a lot of explanatory ("why") end-of-line comments - end-of-line because I like to see the entire function/method in a single screenful rather than three. I also have a habit of aligning the comments from col 80, so that they do not visually disturb the code itself - you look at the comments (only) if you wonder "why". A number of my critics also love to open three source file windows side by side, so narrow that they usually won't see my comments, which are outside of their windows 
|
|
|
|
|
|
Comment for yourself. Some devs will read them... some... if they are coherent and make sense to a different person. And then some devs refuse to take any initiative... so good luck with that.
Jeremy Falcon
|
|
|
|
|
I guess I should have provided context on what I mean as a comment. For as long as I've been writing code, I outgrew quickly code comments that say "increment the pointer" and other trivial stuff. I also like *limited* Hungarian notation: certain prefixes that over time just help me scan the code. Years ago, I picked up the habit that every pointer begins with a lower case p. Key was readability.
As for oxygen and other tools like that, they sometimes help understand the overall system (especially call trees) but development tools have made such advancements that most of the doc has been replaced by tool features (hovering over a variable for example). The best tool I've ever used is Understand from SciTools. Unfortunately, they moved from a perm. license model to monthly fees, pricing it out of my market.
Rather than what, I try to explain why the code does what it does. Example of the table of data - that's what and you can infer why. In my case, I have a piece of common code that runs on 4 different platforms. Thelatest platform has some issues to be worked around, and I found myself trying to explain why. It then occurred to me that I knew the product was reaching end of life, no one will likely read this, just comment in the SVN commit.
After reading all of the replies to my question, it might be wordier, but breaking up the code into 4 different methods (each supporting a specific device) is probably the cleaner approach.
Thanks for the insights.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Sometime in the 1970s one of our users reported a problem entering a date for a future event. The code was not written by us, but we had the source, so I pulled up the code to see how it worked. I found this comment (PDP-10 assembler)
"Thirty days hath September, all the rest I can't remember, except February which never works anyway" There was no code to handle leap year! At least the comment helped us know we were in the right place. That isn't the worst comment I found in code from that source, but the worst would violate nsfw rules.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
