Code should be self-describing, whenever possible. In other words, if you write clear code, you will need fewer comments.

Comments should include:

1. A general description of the class/method and what it does,
2. How objects and methods relate to each other, as an overall architecture.
3. Anything that is not immediately obvious from reading the code, such as obscure performance optimizations.

In general, comments should be written when they are needed, which ideally is when you write the code that requires them.

Avoid comments that state the obvious, or restate what is already clear in the code. The more comments you have, the more comments you will have to maintain when you change the code.

I’d rather suggest anyone writing comments from the beginning of development, since the rationales and the context are fresher in the mind. This will save you a considerable maintenance effort, since recollecting such intents can be exponentially difficult as the time passes on.

There are several rules of thumb for commenting the code, I keep an abbreviated list for practical usage.

1. be succinct on telling what‘s being done
2. leave the how it’s being done to the code, only commenting the non-obvious stuff or general methodology (like referencing a well-know solution, algorithm or relationship)
3. whenever you need to justify a non-idiomatic usage of the language (usually performance tricks require that)

All these items are better noticed by a proper peer-review process.

Write comments as you write the code. They’re there for your benefit as well as the benefit of anyone who may be subsequently reading the code.

You’ve got things half right when you talk about “explain why this block is used” but the debugging stage is just going to be too late for that. If you have to think about why you wrote things a certain way at this later stage, then you’re already in a position where a comment written while writing the code would have saved you time and trouble.

They also serve to help you focus your mind while coding; rather than rushing ahead with something they force you to stop for a short while, think a little more about what you’re doing now, and can prevent you from going down a wrong track.

None of this is to say that while you’re writing the code is the only time you should write comments. If, during any later stage (not just debugging) it seems appropriate to add a further comment, modify an existing one or add a new one where there wasn’t one before (or even remove one that now seems unnecessary), then do so too.

Ideally, comments should be written at the same time as the code.

In the real world, those comments are not nearly as often as needed actually written, so if you stumble across a piece of code that, in your opinion, deserves an additional comment, there should be nothing against adding it later (or commenting upon it if you found it during a review).

Most often I write comments before and instead of code. This way I lay out a plan of the future code in high-level terms.

Then, I add code that the comments suggest. Comments describe what and why is done, code adds the how.

After that, some comments may be redacted, if code is transparent enough; some (much fewer) comments need to be expanded.

This way, I rarely have to add comments to existing code.

Your method will work great IFF every piece of code you write gets thoroughly debugged and you have many passes through it to comment it. Hopefully, you will one day write more code that works fine (more-or-less) on the first try. Which means fewer or no long debugging sessions, which means fewer or no or comments, if you strictly follow a “comment only when debugging rule”.

I would say write the comments as you write the code. If you write code that you think might require extra explanation, write the comments as soon as you realize they might be needed!!

(and yes, you will need to update your comments if your code changes in such a way that the comments are no longer valid)

Comments can be written at any stage, comments SHOULD be written when you believe the code needs explanation and you know that you understand it.

Believing the code needs explanation should almost always be based upon your belief about how easy it is to understand the purpose of the code — if the purpose is clear, then you probably don’t need an explanation as to what it is doing. This is in part the purpose of good naming — so that given a name of a function and it’s input/output, you will understand why the code is needed and why it is doing whatever it is doing.

Comments on the syntax should be extremely rare, pretty much limited to cases where it is BOTH obscure AND possible to misunderstand it to be something else. If it’s simply obscure, then trust that they will look it up if they need it, if it’s simply likely to be misunderstood a + b * c then write it so that it’s less likely to misunderstand a + (b*c). If on the other hand the purpose is unclear (working around a framework/compiler bug for an extreme example) then you need a comment so that the next person can understand why you are doing what you are doing.

Adding comments when you debug is fine, debugging naturally brings you back to older code which you may struggle to understand — and struggling to understand, you know that it needs comments.

This may be why lots of people start off giving comments on syntax — they haven’t yet mastered it, and are still struggling with it a bit, and don’t have enough experience to realize that syntax is something that they will learn and understand later. They expect to have trouble understanding the syntax, and thus provide a comment.

But having this as your normal mode of operation is not ideal, at best it is then helpful the 2nd time you have to debug that code. You should strive to anticipate where you will have trouble understanding the code, and write the comments explaining it as it is written. Don’t expect to get it right all the time, or even most of the time at first. Just try to do better.