|
Indeed. Once I started commenting only what I needed to, my productivity went up. It's embarrassing how much time I used to spend, documenting every little thing:
int i;
Nowadays, I use comments to explain rationale, insert references to background material, and describe version history.
Software Zen: delete this;
|
|
|
|
|
//quote from Colin's post. Used as reference to original post
Colin Davies wrote:
But commenting every line of code like:
// response to Colin's post
I agree with you on that, Colin. A certain level of understanding should be expected.
//signature
"Manifest plainness, embrace simplicity,
reduce selfishness, have few desires."
-- Lao Tzu BW
//end signature
//end post
|
|
|
|
|
///
/// /*brianwelsch wrote:
///I agree with you on that, Colin */
///
/// /* Thanks Brian */
///
Regardz
Colin J Davies
* WARNING *
This could be addictive
The minion's version of "Catch ![Green Alien | [Alien]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/alien.gif) "
It's a real shame that people as stupid as you can work out how to use a computer. said by Christian Graus in the Soapbox
|
|
|
|
|
Worked on complicated highly optimised number crunching code lately? Worked on code that is nessy because it had to do a long-winded workaround to solve a non-intuitive and non-trivial OS or library bug?
And then had to share this code with others?
I thought not.
cheers,
Chris Maunder
|
|
|
|
|
Chris Maunder wrote:
And then had to share this code with others?
You are correct.
Having to share code is the real problem in this and many other sitautations.
What surity do you have that who reads or examines the code will be understand it anyway.
Thus the developer will need to work to the highest common factor realistically possible, and the principles of peer review go out the window.
Having to educate your co-workers is hardly ever in any job description to my knowledge.
Regardz
Colin J Davies
* WARNING *
This could be addictive
The minion's version of "Catch "
It's a real shame that people as stupid as you can work out how to use a computer. said by Christian Graus in the Soapbox
|
|
|
|
|
Whitespace is your friend, use it wisely... I hate downloading code that looks like this:
#include <iostream.h>
void main()
{
cout<<"Hello world!"<
|
|
|
|
|
That last post was me! i wasn't logged in 
~DaN
|
|
|
|
|
That is nothing compared to some of the garbage code that has been posted here 
This is an example of too many enters rather than spaces:
void function
(
int param1,
int param2
)
{
}
If only I could remember what article it was... it was fairly recent 
|
|
|
|
|
I use the tab key religiously, and I line nearly everything up. The result looks something like this:
labels = new Label[9,12] ;
labels[0,0] = new Label() ;
labels[0,0].Image = new Bitmap( "tile.bmp" ) ;
I didn't write this but I love how the {} line up:
protected override void Dispose( bool disposing )
{
if( disposing )
{
if ( components != null )
{
components.Dispose();
}
}
base.Dispose( disposing );
}
|
|
|
|
|
Hmmm. I tend to use K&R style braces:
if (...) {
}
for (..) {
}
but I do tend to include a fair number of blank lines in my code. I've found it's easier for me to read, with blank lines breaking things up every so often. One thing I've always disliked, however, is the extra spaces people put before and after the parentheses in a function call:
SomeFunction ( argument1, argument2 );
Software Zen: delete this;
|
|
|
|
|
|
Gary R. Wheeler wrote:
if (...) { //... } for (..) { //... }
Agreed.
Gary R. Wheeler wrote:
SomeFunction ( argument1, argument2 );
Definitely agreed!
The kindest thing you can do for a stupid person, and for the gene pool, is to let him expire of his own dumb choices.
[Roger Wright on stupid people]
|
|
|
|
|
If you make easily understood source code then the programmer and the viewer will understand it better and should just about speak for itself.
But then again if you comment ALOT then you probably won't find alot of things out and you are spending a huge amount of commenting which when compiling the program will be useless and if you spent more time making and improving better code, then your program, (I think), would be alot better.;)
Don't get me wrong, you should comment it but as little as possible so you or someone else looking at it should understand what it's supposed to do.;P
<marquee>Universal Project... Soon to be a .net
|
|
|
|
|
See my post below - I partly disagree. Well written code can tell you what. But you need comments, or knowledge of what your program does, to decipher why.
Comments are invaluable when dealing with an API from a large, well-known software corporation that occasoinally has bugs or undocumented "features" that have non-obvious workarounds.
"When a man sits with a pretty girl for an hour, it seems like a minute. But let him sit on a hot stove for a minute and it's longer than any hour. That's relativity." - Albert Einstein
|
|
|
|
|
If you recall I didn't say that comments were totally bad if you had read all of it. 
<marquee>Universal Project... Soon to be a .net
|
|
|
|
|
.. but you get none !
:evil:
i'm only pointer to myself
|
|
|
|
|
More often than not, though, you're right...  :puke:
"When a man sits with a pretty girl for an hour, it seems like a minute. But let him sit on a hot stove for a minute and it's longer than any hour. That's relativity." - Albert Einstein
|
|
|
|
|
That's the problem with surveys like this. "Which would you rather lose.. your right hand or your left?"
Good code is written to be understandable, and is well commented.
|
|
|
|
|
"If you can say it in code, do so. Otherwise, say it in a comment."
He made this statement in a C++ class I took from him. This comment  made a profound change in how I documented my code. I used to comment everything, whether it really needed it or not. Now, my commenting is very context dependent. Header files I tend to comment fairly well, providing descriptions for methods and their arguments when they are private. Sources I comment whenever an algorithm is non-trivial, and to partition major pieces.
The end result is that my code is more concise, easier to read, and I'm more productive.
Software Zen: delete this;
|
|
|
|
|
I just finished a 2500 line C project. 20 Comment lines total. Why comment when code is readible?
Cheers
PS: one method comment is:
//if you wanna figure out whats going on here, set up a truth table 
leppie::AllocCPArticle("Zee blog");
|
|
|
|
|
2500 lines? That's all? Small-timer. 
"When a man sits with a pretty girl for an hour, it seems like a minute. But let him sit on a hot stove for a minute and it's longer than any hour. That's relativity." - Albert Einstein
|
|
|
|
|
Gary Wheeler wrote:
Sources I comment whenever an algorithm is non-trivial, and to partition major pieces.
OR whenever you use a library function/API tha thas a bug, and you have to do something contrary to the documentation (or the documentation has a bug) to get around it.
"When a man sits with a pretty girl for an hour, it seems like a minute. But let him sit on a hot stove for a minute and it's longer than any hour. That's relativity." - Albert Einstein
|
|
|
|
|
That's a case where the code can't 'say it' clearly; a comment is called for.
Software Zen: delete this;
|
|
|
|
|
When its good, its out of this world...
When its bad, its better than nothing...
Steven J. Ackerman, Consultant
ACS, Sarasota, FL
http://www.acscontrol.com
steve@acscontrol.com
sja@gte.net
|
|
|
|
|
And not having any makes you cranky?
Software Zen: delete this;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
