2 comments

[ 1.6 ms ] story [ 19.5 ms ] thread
"Code tells you how (or what), comments tell you why"

No matter how meaningful function and variable names are, I'll still take commented code over non-commented code any day, but the rule for good comments is to commend why the code is doing what its doing, not what its doing.

I've worked with enough complex code in my time that I now heavily comment my code and really appreciate well commented code. But, again, don't tell me what the code is doing (provided the code is clear and reasonably named), instead tell me why its doing what its doing.

I suppose the key is not to use comments to offset bad code, but rather use comments to augment already good code. That is, write good code first, then good comments.

In that example you gave you would move the documentation (how a premium customer is defined) into the function.