The task is to invent names for things

[Martin Di Paola]

IMHO, I prefer really weird names.

For example if I'm not sure how to name a class that I'm coding, I name it
like XXXYYY (literally). Really ugly.

This is a way to avoid the so called "naming paralysis".

Once I finish coding the class I look back and it should be easy to see "what
it does" and from there, the correct name.

If the "what it does" results in multiple things I refactor it, splitting it
into two or more pieces and name each separately.

Some people prefer using more generic names like "Manager", "Helper",
"Service" but those names are problematic.

Yes, they fit in any place but that's the problem. If I'm coding a class and I
name it as "FooHelper", I may not realize later that the class is doing too
many things (unrelated things), because "it is a helper".

The thing gets wrong with the time; I bet that most of us saw a "Helper" class
with thousands of lines (~5000 lines was my record) that just grows over time.


On Wed, Oct 27, 2021 at 12:41:56PM +0200, 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 ?
>
>Karsten
>--
>GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
>-- 
>https://mail.python.org/mailman/listinfo/python-list