The task is to invent names for things

[dn]

On 27/10/2021 23.41, Karsten Hilbert wrote:
> Am Tue, Oct 26, 2021 at 11:36:33PM +0000 schrieb Stefan Ram:
> 
>> xyzzy = lambda x: 2 * x
>>
>>   . Sometimes, this can even lead to "naming paralysis", where
>>   one thinks excessively long about a good name. To avoid this
>>   naming paralysis, one can start out with a mediocre name. In
>>   the course of time, often a better name will come to one's mind.
> 
> In that situation, is it preferable to choose a nonsensical
> name over a mediocre one ?


I've often debated this with myself - it's related to adding:

    """Docstring."""

immediately after typing a class/function/method definition - because my
head is too full of the code to be written - and those linters can be
clamorously insistent!

Thus, isn't the answer "yes!".


Cognitive over-load is the issue: We can only hold so many thoughts
in-mind at a given point in time.
(the size of "many" being up for debate, highly variable between
individuals, and between the same person at different times or under
different conditions - see also "in the zone")


With today's powerful IDEs, in particular Find-and-Replace-All functions
(noted that PyCharm has a Refactor facility which includes such, and
with code-aware 'intelligence' cf 'blind' string-matching), it really is
easier to go with a 'first thought name' and the promise of re-visiting
the choice later.

When 'later' arrives, eg when the value is being utilised differently
(an earlier comment in this thread), there is a natural/QA process to
(re-)think the name according to its different aspects over time.


That said... there is a risk that you (OK, "I") don't re-visit the
choice and "asdf" (easy for US-keyboard users) 'slips through' to Code
Review. Oops! You do Code Review don't you?


An opposing thought might be that if you have sat-down and sketched-out
a design - a high-level 'how' you are going to deliver the requirements,
many 'names' will be 'set' during that process - I think an integral
component of Domain-Driven Design (DDD) philosophy.

An eminently-sensible piece of advice underlying such thinking is that
the spec/requirement should be written in the user's terms (those of the
"domain"). Thus, the easiest (and accuracy/consistency promoting) path,
is to maintain the use of that terminology/names all the way through
from spec to code.

Above also reduces my cognitive load - an appealing characteristic for
such a lazy "bear of little brain"...
-- 
Regards,
=dn