IT Employment

COMMENT,COMMENT,COMMENT,COMMENT,COMMENT your code! as you wright not after.

this is the best way to make code readable.

a comment just before a function to explain what the function does, will always help decipher the code in the function.
( since function names are not intuitive to all, even if the name is to you )

Var
NumberOfInvoices : Integer // The Number Of Invoices
Procedure PrintInvoices;
// This procedure prints the invoices
Var
lp : Integer; // LoopCounter
Begin

//Loop though the list of invoices and print each one

For lp := 0 ToNumberOfInvoices - 1 Do
InvoiceList[Index].Print;
End;


Great eh, but this is all too often what people do when told to comment, comment, comment.

Drives me f'ing wild. Total complete utter waste of time, effort & resources and on top of that counter productive;

Comments should be restricted to why, they should be sectioned off somewhere relevant, but they should not break up the flow of the code, nor should they be so far to the right you have to scroll across to read them.
If comments are required to understand what the code does then it isn't readable.
They are useful on occasion though.
An example I ran into yesterday

Procedure TMyObject.FreeResource; Override;
....

Procedure TMyObject.FreeResource;
Begin
//Stubbed out to avoid calling parent's method.
End;

Great I can see that, why wouldn't you want to free the resource though ? Answer after some investigation on my part having looked at how the parent's methods had been overridden or hidden was the resource was never actually allocated and the stub was to simply avoid a warning of abstract methods in a created class message at compile time.

Now that in the comment would have saved me half an hour's investigation. Needless to say the comment has now been beefed up for when in six months time I or some other poor wally has to go near this code again.

Annotated code only helps if the annotation is helpful, the comment comment comment approach is for languages where there is a serious limitaion in the naming of entities.
I' always consider comments in code in a modern language to be an indicator that I know I've written it poorly.
There's nothing wrong with a bit of blurb at the top of the file describing what's in there though, any pre & post conditions, god forbid implicit dependancies etc.

To add on what S junkie said, this is surely the right place for you. Pls try to make the very best of verious section, and make sure you set your focus before logging on ( define your goal(S)). As well, try to ask as much question you can, and make the difference.

At a close, I wish you all the very best, WELCOME...WELCOME....WELCOME....