The task is to invent names for things

[Avi Gross]

Stefan,

I choose not to get involved in a discussion about arbitrary naming rules as many languages and programmers have their own ideas and preferences and rules.

My examples were EXAMPLES and the actual names are irrelevant. Feel free not to use them and I assure you I have no plans to either.

My POINT was that people choose names as being descriptive in many ways, often unique to themselves or to their organizations. A name that may be considered quite useful and explanatory in one context is not in another. Specifically, names chosen using American English may mean little if looked at by programmers elsewhere or if they are chosen with a sense of humor or the like, may not make sense to those who are not in on the ideas involved. Naming a variable PINK (in any combination of upper or lower case you feel like may make you think it fits when using it to count Breast Cancer patients but many will have no idea why you chose that.

I strenuously disagree with many things you quote as being obviously true. Nonsense! Programs need whatever number of variables they need. There is no reason you must reuse the same variable of "i" or "index" for every loop nor why it must be different every time. Nor must names lengths be determined by the length of scopes. You are quoting, presumably, from some document outlining what a corporation or University or such are doing to try to get a consistency across their programmers. Fine, I have seen multiple CONTRADICTORY such declarations and it is often a matter of taste. In some languages I use periods in longer variable names and in others I use underscores and many times I use camelCase, Hungarian notation and others. The compiler and interpreter generally do NOT care.

To bring this back to python, does it have any serious rules or informal ones as compared to others? I have seen places that suggest constants be all CAPS and Classes should be capitalized and regular variables never capitalized and endless variations on such themes. I have seen places they suggest adding parts to names such as the units so you have xxxDollars versus xxxFeet or where they want each variable to contain a similar suffix (or prefix) specifying the type of the object such as int or char or objectXY as one way to make things clearer or help prevent errors. There are MANY schools of thought and I suggest no one right way.

My thought was that no matter what methodology for naming you have, it may not work quite well if the same variable is used in contexts ranging from does it currently exist, how much does it hold, is it "true" as in non-empty, or the value it has when switched to another form of measurement. It is common often to encapsulate something into an object and then use instance variables or functions to address it different ways. So an object called incomedata might be used as incomedata.count in one context and incomedata.nonempty() in another. That is not the same as my talking about synonyms. And note many languages allow you to create somewhat dynamic synonyms such as a view of a subset of something like an array using another variable and allowing it to represent the current state of the main data structure or even change selected parts. It is not at all a foreign concept to have multiple names point to the same things. Often, it helps make the code clearer.



-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net at python.org> On Behalf Of Stefan Ram
Sent: Thursday, October 28, 2021 2:07 PM
To: python-list at python.org
Subject: Re: The task is to invent names for things

Supersedes: <names-20211028185041 at ram.dialup.fu-berlin.de>
[corrected two typos]

"Avi Gross" <avigross at verizon.net> writes:
>if (WeHaveAny)

|Function names should be lowercase, with words separated by underscores 
|as necessary to improve readability.
|Variable names follow the same convention as function names.
PEP 8 (2019)

  The name should not be "optimized" for a certain use case
  (as for the use in an if expression) only. "We", "have",
  and "any" carry little information. A name should pack as
  much information as possible in as least characters as
  possible. So, for me, it'd be something like:

if word_count:

  .

>So, the obvious solution is to ask the language, like Python, to allow 
>variables that are synonyms.

  Programs already have too many names in them. 
  There is no need to add even more, especially
  when they are equivalent, and the average human can
  only hold 7 ± 2 objects (like names) in his short-
  term memory.

>really good names often end up being really long names

  If they are really long, they are not really good,
  /except/ when they have a really large scope.

  Names for a small scope can and should be short,
  names for a large scope may be longer.

  Some very short names have traditional meanings
  and are ok when used as such:

for i in range( 10 ):

  . And, as a "golden rule" for refactoring, I'd say:
  When you see:

i = 0 # word count

  , then remove the comment and rename "i" to "word_count"!


--
https://mail.python.org/mailman/listinfo/python-list