My general rule is that the greater the scope -- lexical or runtime -- of a variable, the more descriptive its name (which often means longer but not always!)
So, for a short lived variable, I'm personally ok with it being short, as in, some random bit of python:
# strip the last char from everything in a list
some_list = [s[:-1] for s in some_list]
IMHO, I don't really think it matters what 's' is here, and I don't think it would would be that helpful if given a more meaningful name. The cognitive load is small.
Conversely, variables that live a long time and/or operate globally are better off with a longer name.
However, I would observe that your example might suggest a coding issue, the tipoff being 'and'. If a single variable is handling two chunks of state, then perhaps it's doing too much and you might be better off with something like:
val documentSavedOnDiskJsonStates...
val pdfSavedOnDiskJsonStates
Not huge savings there, but perhaps also things might get clearer encapsulating these things in a class, with methods like (just making stuff up):
Not saying that this is always the correct approach or valid in your particular case, just making the general observation that IME highly modular code tends to require fewer really long names.
But: the broader the fame/notoriety of the entity, the shorter the name!
Just like in human culture.
Among your friends or family, you have a nickname. In a broader situation, you might go by your first name, and in a broader one still, by your full name.
But: if you're stinkin' famous, then you might get a nickname again, and everyone knows it.
I'm not going to give the Lisp cons function a seventeen letter name just because it is global.
Comments
My general rule is that the greater the scope -- lexical or runtime -- of a variable, the more descriptive its name (which often means longer but not always!)
So, for a short lived variable, I'm personally ok with it being short, as in, some random bit of python:
IMHO, I don't really think it matters what 's' is here, and I don't think it would would be that helpful if given a more meaningful name. The cognitive load is small.Conversely, variables that live a long time and/or operate globally are better off with a longer name.
However, I would observe that your example might suggest a coding issue, the tipoff being 'and'. If a single variable is handling two chunks of state, then perhaps it's doing too much and you might be better off with something like:
Not huge savings there, but perhaps also things might get clearer encapsulating these things in a class, with methods like (just making stuff up): Not saying that this is always the correct approach or valid in your particular case, just making the general observation that IME highly modular code tends to require fewer really long names.The greater the scope, the longer the name.
But: the broader the fame/notoriety of the entity, the shorter the name!
Just like in human culture.
Among your friends or family, you have a nickname. In a broader situation, you might go by your first name, and in a broader one still, by your full name.
But: if you're stinkin' famous, then you might get a nickname again, and everyone knows it.
I'm not going to give the Lisp cons function a seventeen letter name just because it is global.
Agree. Context is king indeed, our assertion is this:
(any type of)documentAnd(convert success)PDFState(categoric variable)JsonStates(chunks of json states).
It's part of an Akka Streams well, stream :) (i/o -> content transform)