Python Forum
Thread Rating:
  • 2 Vote(s) - 3 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[Basic] Naming Conventions (PEP 8)
#1
[Migrated from old forum, originally posted 22 February 2013.]

NOTE: There's definitely wiggle room when it comes to these conventions. Some are more important than others, and you're welcome to read the discussion in the replies. Following these standards certainly won't hurt though ;) 

Python allows any name with upper- and lowercase letters as well as underscores (_). However, there are conventions that the Python community follow in order to standardize things and make reading others' code more easy. We follow PEP 8 (this link links specific to the naming conventions section, and is not PEP 8-comprehensive) but I'll go in order that people learn things and so will be more useful here, rather than the other they use in PEP 8.

---
A better looking PEP-8.org for Humans.

Typical variables
Typical variable names should be descriptive, and may use underscore_style for separating words when it increases readability (they're not always necessary, use your best judgment!). You wouldn't use the variable name x for a string which represents a user's name. You would use nameuser_nameusername or something of the sort. Capitalized is strongly discouraged, and mixedCase is not considered Pythonic, although mixedCase is less of a priority. CamelCase is confusing for regular variables since it is used for classes. Constants are often denoted by ALL_CAPS and underscores separate words. Capitalized_Words_With_Underscores is longer than necessary and terribly ugly.

If you are adding code to a project which uses a style other than what is described here, use that style instead. Consistency is why we do this, and consistency is what you should strive for.

Names to avoid

Quote:PEP 8 wrote:
Never use the characters 'l' (lowercase letter el), 'O' (uppercase letter oh), or 'I' (uppercase letter eye) as single character variable names.


You should also avoid using built-in names, such as "sum". You are unable to use names such as "class" since it is a keyword, however the recommended alternative is to append an underscore like "class_". The extra underscore is preferred over something like "clss".

Functions
Follow typical variable naming conventions for functions. If a function returns the same thing always, don't make it an UPPERCASE_FUNCTION, just do the constant.

Classes
Classes use CamelCase, and should be singular. A "car" class should be Car, not Cars. A big number class would be BigNumber.

Class methods
Same as functions, although the first argument to a method should be "self" and for a static method it should be "cls".

Private class attributes/methods
You can prepend an underscore (_) to indicate that something is private, or use double underscore (__) to denote that something is very, very private. There is controversy over whether the double underscore should be used. (A user can still access a "private" attribute/method, however doing so is discouraged because it could be an implementation detail that can change, rather than being part of the interface for the object.)

Packages
Package names should be lowercase, even when they contain only a single class which should be CamelCase.

Exceptions
Exceptions, being classes, follow class conventions.

Regulars please give feedback on this! And other mods, feel free to make edits if you deem it with doing.


Forum Jump:

User Panel Messages

Announcements
Announcement #1 8/1/2020
Announcement #2 8/2/2020
Announcement #3 8/6/2020