Forum Home
Press F1
 
Thread ID: 37957 2003-09-23 02:12:00 Flow Chart/Diagram/Graph type program, any suggestions Kame (312) Press F1
Post ID Timestamp Content User
177235 2003-09-27 10:18:00 I've commented every line of code before. Might have had something to do with trying to get the three marks for commenting. -=JM=- (16)
177236 2003-09-28 03:05:00 Keeping a flow of what's happening is really to keep me up with what I'm doing, I am not going to eliminate comments over a flow chart as the chart is filled with my ideas of what's happening (and I don't expect people to understand my confusing ideas sometimes).

Graham L was just showing an example, but commenting small things like that is excellent, even if you think you know what it means. You have to realise that even though you know what your program might be doing, even if it's advance you should at least simplify it for beginners who may want to look at what you are doing.

e.g.
int a = 5; // assigns the value 5 into 'a'
a = a + 1; // adds 1 to the value of 'a'

without the comments I could have done something like this, and to beginners they may not know that the above is the same as the below example.

int a = 5;
a = a++;

Now at a beginners level, they may understand what it's doing, but we have to not assume they do, assumption is the mother of all f$%&*kups.

All I have to say is, keep comments there, and explain it in the simpliest terms you can.
Kame (312)
177237 2003-09-28 04:30:00 SNAP. Now I've seen it twice. :D

I've been lucky enough to have been able to use nice languages like Algol and Pascal, whichj allow sensible variable names. Although I never went quite as far as the Burroughs system programmer who names one boolean "Flagtoensurethatanotherflagisnotset", I have found that using the control structures appropriately, and picking names properly, a programme can be read as precise English. One of the aims of Algol was that it could be used as an algorithmic defiinition language, and I've done that too: writing a programme to "work", then rewriting some procedures in assembly code for the speed needed (but leaving the Algol code as the comment to the assembly code).

How's this for a piece of self-documenting code?/isleap % true if leap year
{ year 4 mod 0 eq
year 100 mod 0 ne
year 400 mod 0 eq or and
} defCan you recognise the language?

The management (or lecturer) rule of one comment per line leads to useless comments, which just clutter the page.

I've seen a suggestion that when debugging or updating someone else's code the first thing you should do is put the source through a filter which deletes all comments on the basis that they'll just put you wrong. :D It's very (if sadly) true that it's easy not to fix the comments when you fix the code, so the comments can very quickly become irrelevant to the code as it exists.

I blame most of these problems on line editing and compiling. It's too eay to make changes. :D When you had to punch cards to make fixes, you thought out the consequences before you made changes. Even after we got terminals, I found I neded an hour at the desk before I did an hour at the terminal.
Graham L (2)
177238 2003-09-28 06:08:00 Hi Kame, I understand what you mean about comments and I suppose you cannot have too many of them .

Im hardly a veteran coder but when I first started writing things I used to comment every line because I wasnt confident I knew what I was doing and would look back on previous procedures as examples .

Now I just write what I am trying to achieve and explain particular lines if its not clear . To me it comes down to the level of the audience . I dont explain Dim's or explain things like a = a + 1 as even beginners should know about variables . To me the important question is what is "a" and I put a note saying "a" is a counter or whatever but even thats not often unnecessary .

Each to his/her own :-)
parry (27)
1 2