Re:I no longer understand my PhD dissertation
by javajosh on Sunday February 14, 2016 @09:06PM
(#11101107)
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".
[ Parent
| on HN ]
Re:I no longer understand my PhD dissertation
by vinceguidry on Sunday February 14, 2016 @09:34PM
(#11101206)
If 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.
Re:I no longer understand my PhD dissertation
by tbrownaw on Sunday February 14, 2016 @10:09PM
(#11101313)
The 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.
Re:I no longer understand my PhD dissertation
by vinceguidry on Monday February 15, 2016 @10:22AM
(#11103788)
I'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.