In certain types of code, the purpose of some logic is not clear by itself.<p>A comment can be very valuable to answer the question &quot;why the heck is this being done here?&quot;<p>It&#x27;s valuable because it represents hard-earned knowledge.<p>That thing that is being done there <i>wasn&#x27;t</i> being done there before, and it took weeks to figure out that it had to be done there, for the sake of such and such a race condition that can occur, when the interrupt goes off just when we are doing such and such elsewhere in the driver. It was hard to reproduce the ensuing problem and trace it to this.<p>The comment explains how the system will fall down if not for those lines of code.<p>Systems that have a lot of (or not even a lot of) concurrency going on can be very hard to understand from the static view. Our aim is to produce the dynamic view: to bring to life the collaboration or sequence diagram that we had on the whiteboard. But it&#x27;s not obvious how (or whether) the code actually does that (and <i>only</i> that, ruling out unwanted scenarios).<p>&quot;Why&quot; comments can also make the code more navigable, because they mention other identifiers elsewhere in the code which are related to this code here in ways which are not obvious. The text editor can jump from these mentions to their definitions, which is a big time saver for someone trying to understand that situation.