|
I have seen comments like: "Gets or sets is required flag" for properties like IsRequired. Now that is something I do not really do. I mean isn't it obvious?
I use XML comments on top of classes, methods and properties where get/set does something more than just getting/setting value. Apart from this, I comment before a block where complex processing is going on or where rather weird looking code is present.
|
|
|
|
|
To answer your question, just go to the Lounge. 
|
|
|
|
|
Other reason for comment is that you dont need to go to code to see a description of a function. For example in VS you get the comment of your code in the intellisense. That help you to code more quickly that figure out what does the function by the name (if you are lucky and the name reflect the functionality.
|
|
|
|
|
Missed an option:
I comment code to shame the person whose bug I'm fixing. 
|
|
|
|
|
Be careful,
you might find bugs in your own not previously commented code and blamimg / shaming yourself 
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Oh for sure, that Thrakazog guy is guilty as hell for many horrible designs/bugs over the years. 
|
|
|
|
|
I seem to be the only one (where I am now employed) who comments. Ditto for hand-me-down code from previous employer.
I, for one, will save my ego for more important things: comments are a legacy;
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I recently had a conversation with a cohort where he said, "gee, I wish I'd commented why I wrote this code this way!" I think everybody should learn to comment why and only "how/what" to supplement obscure algorithms. I include myself in that camp, as I hardly ever comment on "why". I'm going to try and discipline myself to do that for a couple weeks and see what I discover.
Marc
|
|
|
|
|
Hello,
I am in the favor of region. Declare a region and within it you can do whatever you feel like. Which also is kind of territorizing your code. So we can look into that section. And yes commenting is also a must.
Thanks a ton,
Rahul
|
|
|
|
|
Argh. I can't stand regions. I have "expand regions" set as the default when I encounter someone's code that uses regions so I can see the dang code.
Marc
|
|
|
|
|
I also comment possible future improvements.
|
|
|
|
|
good point. agree.
Work hard on hard work. That makes you hard. -- A hard worker.
|
|
|
|
|
aboubkr90 wrote: I also comment possible future improvements.
I don't. There's no way my code can ever be improved upon
|
|
|
|
|
"If you can say it in code, do so. If you can't, say it in a comment."
Software Zen: delete this;
|
|
|
|
|
Those who can do code.
Those who can't teach comment.
Just kidding, kind of... 
|
|
|
|
|
Those who don't comment, suck.
Software Zen: delete this;
|
|
|
|
|
I always comment my code, this helps the new person to understand the code easily.
Sometimes, I also comment when I have to visit the code after the testing is complete. Different scenarios are kept with comments so as to remove the unwanted code at the end.
|
|
|
|
|
Ok, how do you select "I just throw random comments at the code view and see what sticks" out of those selections?
|
|
|
|
|
Funny but true...
I hardly write any comment in my code, but I comment the code itself when I am planning to delete it in future after proper testing of new code. 
|
|
|
|
|
I've made a habit of commenting my code thanks to CodeProject. Preparing a source code for an article to be published in CodeProject is not exactly same as developing an end-user application. Readers may read the entire code and tried to understand line by line so comments are mandatory. Based on the viewers questions and suggestions for previous articles, I could decide what exactly should comment in the code of next article.
|
|
|
|
|
If I am in a good mood, I will comment legacy code saying, //fixed joe 05052014.
Then if I have some very complicated business logic that was not documented well, I will try to comment a decent explanation of what is going on.
Otherwise, my naming conventions and KISS Principal should explain the code.
|
|
|
|
|
Then there's the commenting on the comments made on questions regarding code commenting.
Though, when asked if I commented on a comment when that comment made of which was commented on was a questionable comment, I give the standard reply:
"No Comment."
|
|
|
|
|
I initial and date my comments as a matter of habit... Many times has it saved me from the Spanish Inquisition!! (Look, the last time this function changed was 6/5/2008 - it can't have suddenly caused the problem you are referring to!!)
|
|
|
|
|
_Damian S_ wrote: it can't have suddenly caused the problem you are referring to
You wouldn't believe how many times that has not been true for me. The problem is every piece of code relies on a certain set of assumptions. Over time, as operating systems or hardware changes, those assumptions may no longer be valid. Code that worked may stop working or break in subtle ways. Multi-threaded code is my favorite example. I've had code that worked correctly in a single CPU environment break when Hyperthreading was introduced, and then broke again in a multi-processor environment.
Software Zen: delete this;
|
|
|
|
|
Yeah, fair point... I work on fairly run of the mill business apps though, so I would have to be super-unlucky to be shafted like that... but it will come!!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
