Why comments
Thousands of programmers have no bigger fear than appearing as co-author on this page. For that reason they minutely avoid any comment in any code. Meanwhile they enjoy the clear and simple outcome of every function, which returns 3 when parameter var1 is "OK" and var2 stores 15. Three means that the machine will start, the robot will turn left, the program will exit or the contrary or all together or an arbitrary combination of it. Depends on the context, which you can find in the 150 lines upward and the other files of the program. Bad luck, if the function is wrong and should return 4, which is something else or the same. Depends on the context. By the way, there are a lot of more techniques for writing unmaintable code.
I don't understand you, darling
Putting comments in a code brings the question, what a good comment is. In general, I would consider a good comment something that explains the semantics and not the syntax. Somebody who knows programming doesn't need a comment like
// Increment x by one
x = x + 1;
which is however an obligatory comment when it is the only one in a function of 1500 lines.
Nevertheless, even the semantics is difficult to match sometimes.
A list follows with real life examples, what a good comment is probably not.
bool ProcesaTeclaUsuario(void) // de momento es global por problemas con los punteros
For the moment global because of problems with the pointers.
There was no non-global function in that code, but not every function might have the same reason to be global.
num_mens_control++; //TODO tiene sentido???
To Do does it make sense??? Who knows?
Of course, if you are changing code, and you are not so sure if the change was right, you can mark the site with a special word (apart from let a commented old version there). If you really have to change a lot, you might find some variation helpful. These examples are from a file of about 2000 lines.
//TODO
//XXX TODO
//WORKAROUND
//WORKAROUND TO DO IT BETTER
//XXX BAUSTELLE
//XXX BAU 28.06
Baustelle is German for construction place.
On a web-site the hint "permanent construction place" is equally meaningful. Who would expect a web-site to change.
!! rules necesarias para el correcto funcionamiento:
rule void Nr_Set_Visible_Displayed(object Ob_Strip input)
Necessary rules for the correct functioning. Not to mention the unnecessary rules and the rules for the incorrect functioning.
!!------------------------------------------------------------------------
!! start of Md_GbMDW_FPL needed rules
!!------------------------------------------------------------------------
Do you write code, which is not needed?
}
!! END OF RULE EXPERIMENTAL
Okay. You do it.
When communication fails, you still have the possibility to tell others what to do by program code.
!! Note: move this(Ob_GbManCoord) to strip model.
export variable object Ob_GbManCoord;
Of course, you could move it by yourself. But why?
!! New model for waypoints line
model MdGb Md_Gb_Waypoints
Either the comments will be update regularily or this model will be new for ever.
!! Study assigment of colours
if Ob_Fp_Strip.In_Flag_Un_Flag_Field then
Sometimes a computer leans back, and asks itself: In which colour should I paint it?
!! Rule to solve the STR-1207: Panning in Playback mode
Solve it once and forever. Don't even think to use the rule for a different purpose.
TStringList *Valores = NULL; //declarar el objeto, es importante inicializarlo a NULL
Valores = new TStringList; //crear instancia del objeto
Declare object, it's important to initialize it to NULL. Create instance of object.
This is an important comment. Otherwise the reader might think it wouldn't be worth to assign NULL to a pointer, which will be overwritten immediately after.
How to try a better comment
In general you can consider the following ideas for writing a comment.
-
Since a programmer probably knows the programming language, you don't need to explain that again, except if you wrote something weird, for example that the connotation of the operator + is not plus. However, in this case you should consider changing the code - not the comment.
-
Don't repeat the code in your comment. Add fife to x doesn't convey any new information to x + 5. Concentrate on what the x means,e.g. add 5 meters to the position x.
-
Don't forget that identifiers (variable, type and function names) should carry their semantics already themselves. A comment may still be necessary to explain the context in which an operation takes place, e.g. a comment on send_to_printer(document) could be Here the document must be in printer understandable format.
-
Does it matter, when a code or a comment has been written or how often it was changed? Consider this before writing a date in a comment. "New" and "old" gave an idea that there was a change, but not when.
-
If your code files have a header, you should only write the things there that you would have discipline to update. The last change is stored in the modification date of the file, the last author is probably one of the group of people around you, the version of a source file is probably needless. An executable file has a version, and all the necessary source files to build this executable file automatically have that version number. Except if you don't sell working programs but source files.
-
It's not a bad idea to separate code into sections with comment titles. But it's wise to use the same style for the same kind of section.