I think it’s simpler than this: renaming it is a small upfront cost for gradual long-term benefit. Hyperbolic discounting kicks in. Carmack talks about this in his QuakeCon 2013, saying “humans are bad at integrating small costs over time”: https://www.youtube.com/watch?v=1PhArSujR_A
I think it’s simpler than this: renaming it is a small upfront cost for gradual long-term benefit.
Yes, but at some point the cost starts to outweigh the benefit. Eg. going from yyyymmdd to currentDate is worthwhile, but going from currentDate to betterName, or from betterName to evenBetterName might not be worthwhile. And so I think you do end up having to ask yourself the question instead of assuming that all code quality improvements are worthwhile. Although I also think there’s wisdom in using heuristics rather than evaluating whether each and every case is worthwhile.
I agree with the big picture point that things that are sort of siloed off aren’t as important for code quality. I chose this example because I thought it would be easiest to discuss. However, although I don’t think they are as important, or even frequently important, I do think that stuff like local variable names end up often being important. I’m not sure what the right adjective is here, but I guess I can say I find it to be important enough where it’s worth paying attention to.
It’s a small upfront cost for gradual long-term benefit. Nothing in that says one necessarily outweighs the other. I don’t think there’s anything more to be had from this example beyond “hyperbolic discounting.”
I think it’s simpler than this: renaming it is a small upfront cost for gradual long-term benefit. Hyperbolic discounting kicks in. Carmack talks about this in his QuakeCon 2013, saying “humans are bad at integrating small costs over time”: https://www.youtube.com/watch?v=1PhArSujR_A
But, bigger picture, code quality is not about things like local variable naming. This is Mistake #4 of the 7 Mistakes that Cause Fragile Code: https://jameskoppelcoaching.com/wp-content/uploads/2018/05/7mistakes-2ndedition.pdf
Yes, but at some point the cost starts to outweigh the benefit. Eg. going from
yyyymmddtocurrentDateis worthwhile, but going fromcurrentDatetobetterName, or frombetterNametoevenBetterNamemight not be worthwhile. And so I think you do end up having to ask yourself the question instead of assuming that all code quality improvements are worthwhile. Although I also think there’s wisdom in using heuristics rather than evaluating whether each and every case is worthwhile.I agree with the big picture point that things that are sort of siloed off aren’t as important for code quality. I chose this example because I thought it would be easiest to discuss. However, although I don’t think they are as important, or even frequently important, I do think that stuff like local variable names end up often being important. I’m not sure what the right adjective is here, but I guess I can say I find it to be important enough where it’s worth paying attention to.
It’s a small upfront cost for gradual long-term benefit. Nothing in that says one necessarily outweighs the other. I don’t think there’s anything more to be had from this example beyond “hyperbolic discounting.”