Anyone who has worked for some time as a maintenance programmer, and had to untangle someone else's code, will probably try be kinder to the future inheritor of the code they write, and document it profusely. The most important comments relate to a subroutine/function's parameters, and documenting whether the parameters are IN, OUT or IN+OUT. Interestingly, only ADA had such syntax, but Modula-2 had the concept of VAR for parameters that can change, vs parameters that are copied. Later versions of C adopted a "const" parameter flag that would signal to the compiler that the parameter is not to be modified. Knowing what goes in and comes out of every function, and minimizing the outputs, and having clarity as to what is being passed to functions, is probably the single largest signal of the quality of code.
When you look at some code, and are trying to gauge how good the programmer was, in just a few minutes it will be apparent if they bothered to document what goes in and out of a function. In some of the functional languages this is a requirement, and in many ways this is why functional languages are gaining traction fast, because they force you as a programmer to do what you should have done in the first place, which was spell out explicitly what is going in and what is coming out.
Unfortunately people are fetishising functions, as if the subroutine was some magical thing that is new. Subroutines were built into machine language from almost the earliest computers, because it was immediately apparent that certain tasks were done repetitively. Their only purpose is to save duplication of code, and they create a problem for the reader in that as they nest ever deeper, it gets extremely hard to read the code. Everyone knows from their first experiences, that code that executes top down, with no branches or subroutines, is the easiest code to read and debug. What we need is a new computer language that is not so jittery, where you express the task as a straight-as-possible path that is easy to perceive.