7 ms·
Stop Commenting Your Code
- cgore 9y agoNo.
- antonpug 9y agoCould you be a little bit more constructive? It's okay if you disagree - but I'd be curious to hear your side.
- moon_of_moon 9y agoWhats the biggest code base you've worked with?
- dvddgld 9y agoI like your article and the example you used, code clarity is vital. Poor code is often accompanied by many poor comments which only helps in overwhelming the next poor soul who has to read the code. However, I think that the larger the project, the more sense it makes to comment heavily. Again, code clarity needs to be a priority, but so does comment clarity, so much time is spent reading code by humans who are optimized to parse natural language. So we should cater to our users, not just the users of our executable, but the users of our source too!
- cgore 9y agoI could ... but I'd rather not comment too much :D
- cgore 9y agoMore seriously: yes, you should name functions/variables/etc. reasonably. And often if you write a comment, you will find you are actually explaining away a wart. But often you need to document business logic, code that needs to be written in a less than clear way for performance reasons, explanations of why you chose approach A instead of what would seem like another perfectly reasonable approach B, URL links for standard doc PDFs, and a million other little things. There are comments that aren't necessary if you write your code better, but there's others that are needed even if you write your code perfectly.
- antonpug 9y agoDocumenting business logic works much better via Spec files - if you have BDD test files Given/When/Then format, that'll go a long way in describing functionality, in my opinion.
- saas_co_de 9y ago> Heavy code commenting is a symptom of bad code. I used to believe that comments were unnecessary for good code but eventually found this to be false. Now I do code annotation where every single line of code is commented. This allows the entire program to be read as plain english which is much faster and less mentally taxing than trying to read code.
- antonpug 9y agoSarcasm? Or am I misunderstanding your comment? :) You annotate "every line"?
- saas_co_de 9y agoIn most cases yes. I make sure the comments provide a complete plain language description of the program. Reading english (or whatever your native language is) is much much faster than parsing code.
- antonpug 9y agoIt's not hard to understand what this.completePurchaseProcess(paymentInfo) does.
- Beached 9y agoStill requires more brain processing then plain English, and if your spending hours parsing code it is taxing and reduces your overall productivity.
- antonpug 9y agoThere must be an insane amount of cognitive overload when having to parse through 2x the number of lines because every line of code is accompanied by a line of comment.
- saas_co_de 9y agoRight, it is not about whether or not the code is complex and difficult to understand. That is the traditional (and bad) commenting advice: that you should add comments to code that is difficult to understand. The point of commenting everything is to allow the program to be understood entirely from comments, so that when you are maintaining a code base you rarely have to read code, and instead are working with native language. I would comment your example like this: // complete purchase process this.completePurchaseProcess(paymentInfo) When you have "complete purchase process" written out as english words you can process that much more quickly than "this.completePurchaseProcess(paymentInfo)"