4 ms·
A good marker for when comments are going to be useful is when something stumps you, and then you fix it and/or figure it out. Chances are, when you read the co
by javajosh 11y ago
A good marker for when comments are going to be useful is when something stumps you, and then you fix it and/or figure it out. Chances are, when you read the code again it will stump you again - or on re-reading you might not even realize there was an issue. So I comment the change. It's usually something simple like, "This cast avoids a special case in method X", or along those lines. The comment is the "why" where the code is the "what".
- vinceguidry 11y agoIf I run into that situation, I refactor the code so that I can better understand it the next time. To not do so is to waste all that time you spent understanding it. > It's usually something simple like, "This cast avoids a special case in method X", or along those lines. If I had an issue like that, I'd fix method X to be more accepting of unclean inputs.
- tbrownaw 11y agoThe problem is that method X is a remote invocation into another system that has different change-control procedures, a different ticketing system, and a different release schedule.
- vinceguidry 11y agoI'd use a gateway class and intention-revealing method names, even if all that method was doing was casting a value. I'd call it ".edge_case_fix", (but described better than "edge case") and do the same for every weirdness in the external system that requires workarounds.