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 alwaysyyyymmdd; 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).
Agreed! FWIW, I did realize that there are those issues with my example and that the post would be improved by using a better one (in addition to using multiple examples instead of just a single one). But I had trouble thinking of good examples and knew of the current one from here.
In that example I see that the actual format is yyyy/mm/dd rather than yyyymmdd. I definitely don’t like the name yyyymmdd in that case; to me it suggests no separators. (I might advocate for switching to yyyy-mm-dd and using a name like currentDate_iso8601, though that’s a bit unwieldy.)
I’m aware that the
currentDate
versusyyyymmdd
thing is only an example, but I’m not sure it’s a good example because it’s not obvious to me thatcurrentDate
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
oryyyymmdd
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 alwaysyyyymmdd
; 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
orcurrentDate_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).Agreed! FWIW, I did realize that there are those issues with my example and that the post would be improved by using a better one (in addition to using multiple examples instead of just a single one). But I had trouble thinking of good examples and knew of the current one from here.
In that example I see that the actual format is
yyyy/mm/dd
rather thanyyyymmdd
. I definitely don’t like the nameyyyymmdd
in that case; to me it suggests no separators. (I might advocate for switching toyyyy-mm-dd
and using a name likecurrentDate_iso8601
, though that’s a bit unwieldy.)Ah. I didn’t even notice that but that’s a great point. I also think that
yyyymmdd
suggests no separators.