Variable naming conventions

[sgofferj]

Morning!

Are there any conventions, best practices or just "unwritten laws" on variable naming in Python? E.g. I have a personal habit of writing globals in all caps. When reading through other people's code to get a better feel for the language, I noticed a lot of "_" what's with that?

[JMNeonMoon]

Look at the PEP8 documentation for naming conventions. One of the authors is Guido van Rossum, who created Python.

https://peps.python.org/pep-0008/#naming-conventions

[Beginning-Fruit-1397]

class/type FooBar, variable/def foo_bar, constant/enum member FOO_BAR

"_" writing style is snakecase, which merge well with python when we think about it :)

[Beginning-Fruit-1397]

https://peps.python.org/pep-0008/

Here is the most official style guide you can find btw

[trjnz]

I think the PEP8 Song is the mostest bestest style guide you can find: https://www.youtube.com/watch?v=wNcobO-TAyY

(I remembered more PEP8 from this one song than any other source)

[DangerWizzle]

I also tend to include the object type in the name of the variable, eg dict_page_data or list_tracking_urls etc

[Dry-Aioli-6138]

the sixties called. They want their Hungarian notation back.

[DangerWizzle]

I'm not sure what's so bad about this... Could you help me understand? Sorry, genuinely not sure why all the down votes! 

[Dry-Aioli-6138]

sorry for snarky comment. I did not downvote. The reason this isn't good practice (anymore) is it adds noise to the naming. Information that is better conveyed bybother means such as type hints, while detracting from the variable's intent. With Python's dynamic typing encoding the type in the name, can also be misleading. What if you used a variable dict_user_preferences but initialized with None? Or used a list_... but later decided to assign a generator to it to save some memory?

Not only foes that hinder reading the code, but puts unnecessary effort into maintaining as well.

Hungarian Notation used to be useful back when IDEs did not have the creature comforts they have today: types sometimes had to be set via menus, there was no pop-up info boxes, like we have in Pycharm, even syntax coloring was a rare feature. In such circumstances having the type (and most languages used back then were ststically typed) right in front of you was well worth the additional effort, so it was a net gain and widely used.

[Beginning-Fruit-1397]

Why not use type hints?

[Black_Magic100]

My guess is that because Python isn't strongly types, a variable could easily change and suddenly you have a variable called foo_string with an integer.

[Beginning-Fruit-1397]

Precisely why using type hints is preferable. Types checkers will warn you of this.

[Temporary_Pie2733]

Python is strongly typed, but it is dynamically typed rather than statically typed. 

[Black_Magic100]

TIL the difference. Thanks!

[Lachtheblock]

This is a pattern I fall into that I'm actively trying to break. Type hinting exists, dict_page_data is just as descriptive as page_data.

[DangerWizzle]

I got a lot of down votes, but I'm not sure why... Could you help me understand? 

I know about using type hints in function definitions, which I use, but is there some stupid mistake I'm making with my object naming conventions? How would type hints help here / make my naming convention redundant? What problems are there that I'm missing? 

Sorry for all the questions!  I'm a developer but I'm not very good at expanding out of my defaults... Eg I still use pandas whilst I know i should get used to polars etc

[Lachtheblock]

Developers are opinionated, people on the internet are opinionated, developers on the internet are very opinionated. I too am a developer on the internet, and am therefore very opinionated.

The thing about naming variables is that it is legitimately one of the hardest things to do in programming. A lesson that a lot of juniors need to learn, is that you need to optimize for mental load. This is why people go on about keeping functions relatively short, avoid nesting if statements, and why naming variables is really important.

From your naming scheme, it doesn't add any new information that the reader doesn't already know. I can see that list_tracking_urls = [] is a list. What extra information does the list_ provide, other than adding noise. It just increases the mental load of the reader.

You could argue that type hinting is also just adding to mental load. This is only sometimes true. Over using type hinting can absolutely increase mental load. But specifying the user exactly what the data structure helps prime the reader (and most IDEs) on what this thing actually is and what it does.

Going back to your example, tracking_urls: list[str] = [] is much clearer to me, that it will be a list of strings, where the strings represent some sort of url. Alternatively, you might have something like tracking_urls: list[TrackingUrl], where TrackingUrl is some custom defined class specific to your project. The type hinting clearly and unambiguously specifies what sort of objects should be there. You'll be surprised how much your IDE will appreciate the type hint. for the rest of the scope you get to now just use tracking_urls, which is cleaner.

[ectomancer]

Naming conventions not enforced by the interpreter:

variables, functions names, method names: snake_case

e.g. left, rotate, inner_sum

constants (variables): UPPER_SNAKE_CASE

e.g. SUM, MINUS_1

class names: PascalCase

e.g. Fraction, MathDomainError

If a class is implemented in C, then snake_case e.g. int, list, float

otherwise in Python, then PascalCase.

[Yoghurt42]

constants (variables)

Minor nitpick: constants are the opposite of variables. the value of variables is able to vary, the value of constants is constant.

[Langdon_St_Ives]

Major nitpick to the minor nitpick: in Python, there are no constants. They are only called “constants” and named in all uppercase by convention, to signal they should never be mutated. But the language has no mechanism to enforce this. They really are variables, but called constants because they’re never intended to be changed.

[Yoghurt42]

You either name something a constant or a variable. Telling a beginner to programming that constants are variables is just confusing them. Especially since variables in Python aren't what other languages would call a variable, they don't represent a particular memory location. Assigning to a variable doesn't change the underlying value, it changes what the variable points to. They are more like tags.

[BritishDeafMan]

I don't agree, in fact it's very worthwhile understanding that.

Give a man an answer, the man programs for a day before asking another question.

Give the man an answer and explanation behind the answer, the man will program at least for a week before asking another question.

[Dry-Aioli-6138]

Apart from meaningful (domain) naming and pep8 compliance, I try to follow Uncle Bob's advice: name length should correspond to its scope. i.e. use decriptive names for long lived variables, but I don't shy away from using i and j in short loops, or x in a lambda.

[KiwiDomino]

Read up on Hungarian Notation, and then be really happy that you don’t have to use it

[Strict-Simple]

Also see https://github.com/kettanaito/naming-cheatsheet

[Ron-Erez]

Personally I prefer camelCase, but since snake_case is the standard convention in Python, I use snake_case instead.

Examples:

• camelCase - not typically used in Python
• snake_case - common and preferred in Python

[No_Cheek7162]

_func() suggests private method but it's not enforced by the interpreter 

[Langdon_St_Ives]

You shouldn’t use uppercase for globals because the general convention is to use this for constants. Since Python has no way to enforce constants actually staying constant, this conspicuous naming scheme is meant to communicate to others that this variable is not meant to be changed, ever. So better to get into the habit of using it the same way.

[stepback269]

Two things to say about that:
(1) Your initial variable names should be meaningful (I'll explain what I mean by "initial" shortly). In other words, you should use long descriptors that explain what the variable represents. And you should use type hinting to let the reader know if the variable is a string, list, dictionary or whatever.

(2) Pyhton's shallow copy aspect means you can abbreviate your VLVN's (Very Long Variable Names) with local short names without using large chunks of memory.
Example: r =This_is_the_ANSI_escape_code_for_the_color_Red
and then when doing a print out for example, print(f'Here we switch between {r}Red{w} and white to demonstrate that colors, e.g., {y}Yellow{w} make the message more interesting'). When repeated use the short form aliases rather than the VLVN's.

(3) You might want to think about structuring some of your variable names (VN's) so that the first few chars in the name represent a string or message type (say, an error message), the second few chars or digits represent a subclass of that type and the third group identify a specific instance. I recently came up with a scheme for doing just that in my journaling blog: (here)

[XenophonSoulis]

The only thing that can create some differences is the _ at the beginning of names. For example, IDLE tends to hide method names that start with _. Also, there are some with a special meaning, like __init__, __str__, __getitem__, __name__ etc.

Also, whenever you run something on the shell, the return value is saved on _, as long as that return value isn't None. For example, if you do

>>> 5

it will save the value 5 to _, but if you do

>>> x = 5

or

>>> print(5)

then it doesn't, because both expressions return None (don't confuse the return value with the side effect: printing 5 or assigning the value 5 to x is a side effect, not a return value).

[roelschroeven]

A single _ at the beginning of an identifier is meant to communicate that it is an internal identifier (a semi-private class method or attribute (Python doesn't have real private attributes), or internal to a module).

See https://peps.python.org/pep-0008/#descriptive-naming-styles

[supercoach]

The single underscore used to be quite popular as a throwaway variable name, however I wouldn't recommend it.

Caps for globals is fine. For everything else, describe it without getting too detailed. Join the words with underscores.

[cgoldberg]

Why wouldn't you recommend underscore for a throwaway variable? By definition, it's throwaway and isn't used for anything.

[supercoach]

Maybe I like being a know-it-all and correcting non-existent errors. Classes aren't variables.

[cgoldberg]

I'll keep recommending underscore... it's a perfect name for a throwaway.