What should the comment say in the code? What happens in the next block of code, or what should happen as a result of executing this block of code? What does the practice suggest / require in this question?

  • one
    both. That in a month there would be no questions like "what is it? Why is -1 wrote or delete this file here?". But without Captain Obvious. - KoVadim
  • one
    There is an opinion that the presence in the code of comments speaks of its poor quality (DOC comments do not concern of course) - rjhdby
  • The lines you select are equivalent in the working code - vp_arth

3 answers 3

A good comment is an unwritten comment. You should strive to write code so that comments are simply not needed.

The problem with comments is that

  • Often they are in one place, and remember them they need them in another
  • the compiler cannot verify the truth of the comment, therefore the comment becomes outdated when the code changes

Let's go through the frequent cases in which comments are unnecessary.

  1. If you want to comment on what a variable is for, throw out a comment and change the name of the variable to a more appropriate one.

    int n; // количество страусов 

    better to replace

     int numberOfOstriches; 
  2. If you want to report that some condition is met, it is better to put an assert :

     // тут pBFG не может быть nullptr-ом, проверка не нужна pBFG->fire(); 

    better to replace

     assert(pBFG); pBFG->fire(); 
  3. If you describe in a comment what exactly a piece of code does, it makes sense instead to allocate this piece as a separate function , and make the meaning of the code its name.

     // нормализовать вектор скорости double temp_length = sqrt(velocity.x * velocity.x + velocity.y * velocity.y); velocity.x /= temp_length; velocity.y /= temp_length; 

    better to replace

     void Normalize(vector& v) { double length = sqrt(vx * vx + vy * vy); if (length == 0.0) throw argument_exception("zero length vector"); vx /= length; vy /= length; } 
     Normalize(velocity); 
  4. If you describe self-evident things in a commentary, it’s better to just throw out this comment.

     // этот класс представляет точку class Point { public int X; // координата X public int Y; // координата Y } 

    not a bit lost in readability in this form:

     class Point { public int X; public int Y; } 

    (and if meaningless comments are required of you by coding standards, ask for changes to these standards!)

Thus, what happens in a section of code should be as clear as possible from the piece of code itself. If not, improve it.

If the comment is in fact the documentation for your code, there's nothing you can do, you do not need to delete it.


Those few places where comments are really needed are descriptions of the algorithms used, optimizations, documentation of bug fixes and non-obvious solutions. Here again, try to write about why you are doing what you are doing. And how exactly you are doing should be clear from the code.

    "Well, you, sir, and you set tasks" ... (c) K / f "Formula of love"

    There are no requirements for comments. You see, it's like asking - the story should describe the author's intentions or the actions of the characters? The statement itself is strange - what exactly to write in the commentary ... And it’s quite strange to distinguish between "what is happening" and "what should happen".

    In fact, the code should be written in such a way that it alone would comment on what it does. It was not thought up by me, but I agree with this, in general. And it is certainly not necessary to comment in the spirit of "assigning the sum of two others to a variable" :)

    Write comments so that after a year or two you can look at the code and figure out what it does.

    Separately, I would highlight comments about what you need to remember to do :)

    If you work in a team - then work as decided by the team.

    At the end I will quote Sutter:

    Do not prescribe the style of comments (except when special tools use them for documentation), but write only the necessary and useful comments. Instead of comments, write where possible, code.

    • TODO important, yes. - user207618

    Good comments in the code (and not in front of functions, etc.) should explain why this piece is needed to solve the problem.

    It is likely that to understand this "why", you will need to describe the state of the source data and what happens after the execution of the commented code.

    And how exactly this is implemented, it is desirable to tell the code itself .