|
Paul Oss wrote:
Broad comments can help eliminate entire sections/functions very quickly.
Agreed !! with an additional emphasis on Broad.
Paul Oss wrote:
But I can tell you from experience, that our development time dramatically reduced once we added just a few INFORMAL practices.
I use to quite heavily comment stuff, and "refactor" code to be more understandable by peers.
To be honest I often find comments harder to understand then the actual code, and this includes my own comments.
Seriously I think when you are actually coding the perspsctive of what a later reviewer will understnd of the comments is influenced by your own mind state at the time. Thus maybe the best person to comment code is not the actual developer.
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
|
|
|
|
|
Colin Davies wrote:
To be honest I often find comments harder to understand then the actual code, and this includes my own comments.
Seriously I think when you are actually coding the perspsctive of what a later reviewer will understnd of the comments is influenced by your own mind state at the time.
No doubt that this can be the case. But that still goes back to the perfect world scenario. If you can't understand the comments, then you're back to square one and having to interpret the code- nothing lost. I don't think that I've ever lost anything significant by difficult to read comments, other than the fact that I will admit that the annoyance factor is high. I may not be losing time, but it makes my blood boil when I spend 4 hours going through nearly unreadable code only to find the comments annoyingly vague. I remember one of my favorite comments that was often made by a particular programmer... a comment I never really deciphered was (in an old version of a business basic (mainframe stuff)):
REM DO VAL SH*T
To this day, I never figured it out.
The only place where time can be lost by comments is when they're logically wrong. But in my experience this has been relatively rare.
Some of you may disagree with the technique, but when I suspected that a one line comment would leave more questions unanswered than answered, I would simply write a whole paragraph describing my reason for doing what I did, what the weaknesses were, where future problems could arise, and how future programmers might deal with changes-- and sometimes my thoughts and feelings on the subject at large. And honestly, they were the most useful later on. Because yes, Colin, I do have to admit, there have been times-- albeit rare-- that I didn't know what my own comments meant.
Paul
|
|
|
|
|
Instead of //Get patient master record from database, parse., how about:
<br />
PATIENT_RECORD * pPatientRec = getPatientRecord();<br />
parsePatientRecord(pPatientRec);<br />
- Renault
|
|
|
|
|
So... what you're saying is make code easy to read. See previous remarks.
|
|
|
|
|
Wow. You're serious.
Your attitude is part of the reason most software sucks.
Colin Davies wrote:
If they can't understand it without comments, then that's actually good, because you don't wan't some 3rd rate hack messing with your masterpiece.
Most maintenance programmers _are_ third rate hacks. That is to say, maintenance programming is usually the first assigment programmers get when they start a job. So you think it's OK to make the code impenetrable so that maintenance programmers can't work on it?
|
|
|
|
|
Jim A. Johnson wrote:
So you think it's OK to make the code impenetrable so that maintenance programmers can't work on it?
Actually, I think its a darn good idea. The Maintenace programmers are likely to make modifications that will cause new problems and a whole new cycle of maintenance will need to be paid for by the client.
Mediocre programmers touching valuable code and being led by comments sounds dangerous to me.
Without comments these programmers will need to both learn what is going on and how it occurs if they want to make changes. Alternatively they can write a replacemmet class or procedure.
The real problem is that at both development and maintenance the management are likely to push for early completion resulting in substandard work.
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
|
|
|
|
|
Colin Davies wrote:
Actually, I think its a darn good idea. The Maintenace programmers are likely to make modifications that will cause new problems and a whole new cycle of maintenance will need to be paid for by the client.
Cloin. You're approaching utopian arguments. This is like the people who say a safety on a firearm is completely unnecessary because if you have a safe handler, the firearm will never accidentally go off. You're right. But that's in the year 2976 when we all walk around in white linen clothes, put our hands together, bow and say 'greetings brother' when we cross paths on the street. But until then, the world aint perfect, therefore we institute things called 'building codes', 'traffic lights', 'road signs', 'blade guards and well commented readable code.
Paul
|
|
|
|
|
/*
Write a good documentation, with all features like procedure header, function description,... . See, you don't need any comment in your code. And if the other don't understand your code-he's just not good enough for working with your code.
*/
Comments are only useful in one language-vbasic. Basiccode have to look like this.
Sub Form_Load()
'Dim a as Variant
'Dim b as Variant
'Init a, b
End Sub
//VB-looks much better with comments.
//Excuse my bad English 
|
|
|
|
|
What a bunch of crap, Colin!
Most engineering has some type of blueprint. All the programmer might get is the bit of comments left by the fella before him.
Not every programmer is an expert in the language they are coding in. whether it's the one creating the mess or maintaining it. Coments are the only way to help give the next guy a clue as to what you were aiming at.
"Manifest plainness, embrace simplicity,
reduce selfishness, have few desires."
-- Lao Tzu BW
|
|
|
|
|
brianwelsch wrote:
Most engineering has some type of blueprint.
Yes, but the blueprints are for the designer or the project creation team to develop. The programmer is working to there specification, he/she should not be developing the project.
Have you ever seen a Maintenance programmer ask to look at the original user requirements or specification?
brianwelsch wrote:
Coments are the only way to help give the next guy a clue as to what you were aiming at.
What about logic and ability, and dataflow analysis and deskchecking, have we left those skills in the dask ages ?
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
|
|
|
|
|
Colin Davies wrote:
What about logic and ability, and dataflow analysis and deskchecking, have we left those skills in the dask ages ?
In the past 18 mths. I've coded a c++ project from scratch with very few specs. It was being redesigned halfway through, because of some new ideas from the powers that be. Also, it was my first C++ project beyond classroom code. So the code I added through helped me quickly figure out what I was thinking and what was going on.
Currently, I'm dabbling in assembly, another new language for me, which isn't even standard, but littered with macro calls. I'm grateful for the couple of comments which are given.
I do alot of plotting out by hand, following data through by hand, etc, but the clocks ticking.
"Manifest plainness, embrace simplicity,
reduce selfishness, have few desires."
-- Lao Tzu BW
|
|
|
|
|
(ducks grenades being lobbed by Davies)
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote:
(ducks grenades being lobbed by Davies)
Nah, I wouldn't do that.
I didn't really expect anyone to agree with me though.
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
|
|
|
|
|
When I'm in a 'let natural selection take its course' sort of mood with regards to my co-workers, I agree with you. Fortunately for them, that only happens a couple times a week  .
If you take a look at my post[^] below, you'll see how I choose what to comment. If it is more consise to say something in code, I'll do so. If it's more straightforward to say it in a comment, and let the const's fall where they may, I'll do that.
Software Zen: delete this;
|
|
|
|
|
Maybe I have been turned away from comments and understandability in recent years by the ammount of over commented understandable code that is poorly written.
I think if some programmers put as much effort into programming well as what they do to commenting then we would be all a lot better off.
Yes, there are places for comments, in the start of files, and in headers for access, etc.
But commenting every line of code like:
iLoop++;
has become far to prevalent.
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
|
|
|
|
|
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 "
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;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
