Taking the outside view on code quality

I'm aware that the currentDate versus yyyymmdd thing is only an example, but I'm not sure it's a good example because it's not obvious to me that currentDate is necessarily better.

If this thing is a string describing the current date then there are at least two separate pieces of information you might want the name to communicate. One is that it's the current date rather than some other date. The other is that it's in yyyymmdd format rather than some other format.

Whether currentDate or yyyymmdd is more informative depends on (1) which of those two things is easier to infer from context (e.g., maybe this is a piece of software that does a lot of stuff with dates in string form and they're always yyyymmdd; or maybe the only date it ever has any reason to consider is the current date) and (2) which of them is more important in the bit of code in question (e.g., if what you're doing is working out which month it is, that operation is the same whether you're dealing with today's date or something else, but it depends a lot on the format of the input).

It might actually be better in some cases to call the variable something like yyyymmdd_now or currentDate_ymd8 (the latter only makes sense if in your code there are a few different string formats in use for some hopefully-good reason (maybe you need to interoperate with multiple other bits of date-handling software), so that giving them codenames makes sense).

I'm not sure inside/outside is what's mostly going on when you're on the fence about whether making a minor name improvement is worth it. It seems to me more like the following things:

• Looking at a single decision rather than the policy it implies. (Cf. "How I lost 100 pounds using TDT [LW · GW]".)
• Changing things has costs as well as benefits; if you rename the variable there's a (hopefully small) chance that you screw it up somehow and break things. Note that this needs to be considered even when you zoom out, even when you consider policies as well as individual decisions, and even when you take the outside view. (Would you rather work on a stable codebase or one where things keep being renamed as other people decide that some name is better? Would you rather concentrate on fixing bugs and adding features, or would you rather keep having meetings where everyone discusses ten variables they think have slightly the wrong names? Would you rather have bugs turn up every now and then because someone renamed a variable but forgot about one place where it's used, or didn't update a bit of documentation?)

This is only tangentially related, but in cases like this, the strategy of improving variable names when you're working on a piece of code is significantly more valuable than searching for code to refactor and improve.

It's true that improving a random variable name in your code base is not a big win, but:

• Since you're already looking at this piece of code and presumably making a change, the cost of changing the variable name is lower than if you were changing a random part of the code.

• The fact that you're looking at this piece of code and not a different one is evidence that this is something people are more likely to look at than usual, so the benefit of improving it is higher than improving a randomly chose variable name.

Because of these two things, the procedure "improve code you're working on" is signifantly more valuable than you'd expect if you think the procedure you're following is "improve all the code".

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

My own relationship to naming is more about taste. I want to be person who doesn't write crappy code but who writes good code and thus I don't commit code with crappy names.

I feel there is something else going on here too.

Your claimed outside view asks us to compare a clean codebase with an unclean one and I absolutely agree that it's a good case for using currentDate when initially writing code.

But you motivated this by considering refactoring and I think things go off the rails there. If the only issue in your codebase was you called currentDate yyymmdd consistently or even had other consistent weird names it wouldn't be a message it would just have slightly weird conventions. Any coder working on it for a non-trivial length of time would start just reading yyymmdd as current date in their head.

Tge codebase is only messy when you inconsistently use a bunch of different names for a concept that aren't very descriptive. But now refactoring faces exactly the same problem working with the code does..the confusion coders experience seeing the variable and wondering what it does becomes ambiguity which forces a time intensive refactor.

Practically the right move is probably better stds going forward and to encourage coders to fix variable names in any piece of code they touch. But I don't think it's really a good example of divergent intuitions once you are talking about the same things.