4 ms·
put a comment at the top of your function that says what to expect about the return value. Great, so now the documentation for the function will promise to ret
by MartinCron 14y ago
put a comment at the top of your function that says what to expect about the return value.
Great, so now the documentation for the function will promise to return a motorcycle, but instead return either a bunny or a toaster.
There are lies, damn lies, and boilerplate code comments.
- mistercow 14y ago>Great, so now the documentation for the function will promise to return a motorcycle, but instead return either a bunny or a toaster. Not if you follow the second part of my above advice. >There are lies, damn lies, and boilerplate code comments. Since when is a comment that explains what a function does "boilerplate"? I think you are confused.
- MartinCron 14y agoI've often had to work with code where the comments indicated an entirely different intention than the implementation. As a result, I'm a little paranoid and skeptical, that's all. I also don't like the idea of having to comment each and every single function. If you have to write a comment to explain what it does, maybe you haven't named it properly?
- prodigal_erik 14y agoThere are a few people who are cautious and methodical enough to specify all types in comments and keep them correct. But you need an entire team of them, because type comments which are only mostly correct would be worse than useless. And an entire team wouldn't choose a dynamically-typed language that makes those showstopper bugs more likely.
- mistercow 14y agoWell, if you're having major problems keeping the project's code and comments in sync, no compiler will save you.
- MartinCron 14y agoThat's exactly how the compiler saves you. A strongly typed routine signature contract is a like comment that cannot get out of sync.