3 ms·
If your code comments are breaking any DRY principles, then it's likely it's because they're explaining what your code is doing. I agree that properly named var
by redact207 13y ago
If your code comments are breaking any DRY principles, then it's likely it's because they're explaining what your code is doing. I agree that properly named variables and well structured code should be easy to understand if you want to know what it's doing.
The purpose of comments are to say why your code is doing what it's doing. These sorts of "why" comments should be encouraged, not avoided.
- ajuc 13y agoYes, especially design decisions and reasons for stuff, that isn't obvious, like why this is looked up each time, and not cached, or why the data representation choosen is as it is, and not something simpler/faster, etc. But there are ways to move some things from comments - gotchas can be made unit tests instead of //WARNING!!! in comments - made a test that checks the implementation for the error that shows when you cache this thing that can't be cached - even if somebody miss the warning in comments he will surely notice the problem when the test fail (comment should still be there so people that read code before making changes won't have to wait AFTER they changed stuff and run unit tests to see they shouldn't do this). One great practice is to make unit test for every easy-to-reproduct bug, check before you fix the bug that it fails, fix the bug, and commit both test and the fix in one commit. Some comments can be also moved to commit messages instead - especially comments that explain why something was changed - you can always blame code and see relevant commit messages, and if the code changes blame won't show commit messages for the lines that aren't there. Comments may be still there after a change that made them misleading.