Skip to content

Instantly share code, notes, and snippets.

@bachloxo
Forked from etigui/python_naming_conventions.md
Created November 10, 2022 13:07
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save bachloxo/230674ac7cace076ab96128eeb91091b to your computer and use it in GitHub Desktop.
Save bachloxo/230674ac7cace076ab96128eeb91091b to your computer and use it in GitHub Desktop.
Python naming conventions

Python naming conventions

This document gives coding conventions example for the Python code. This style guide evolves over time as additional conventions are identified and past conventions are rendered obsolete by changes in the language itself.

1. General

  • Avoid using names that are too general or too wordy. Strike a good balance between the two.
    • Bad: data_structure, my_list, info_map, dictionary_for_the_purpose_of_storing_data_representing_word_definitions
    • Good: user_profile, menu_options, word_definitions
  • Never use the characters as single character variable names:
    • “l“ : lowercase letter el
    • “O“ : uppercase letter oh
    • “I“ : uppercase letter eye
  • When using CamelCase names, capitalize all letters of an abbreviation (e.g. HTTPServer)

2. Packages

  • Package names should be all lower case
  • When multiple words are needed, an underscore should separate them
  • It is usually preferable to stick to 1 word names

Example:

pyramid
[or]
pyramid_giza

3. Modules

  • Module names should be all lower case
  • When multiple words are needed, an underscore should separate them
  • It is usually preferable to stick to 1 word names

Example:

pyramid.py
[or]
pyramid_giza.py

4. Classes

  • Class names should follow the UpperCaseCamelCase convention
  • Python's built-in classes, however are typically lowercase words
  • Exception classes should end with (suffix) “Exception”

Example:

    class PyramidGiza():
    class InputException(): # Exception

5. Global (module-level) Variables

  • Global variables should be all lowercase
  • Words in a global variable name should be separated by an underscore
  • It is preferable to use these variables inside one module only

Example:

    pyramid_giza = "pyramid of giza"

6. Instance Variables

  • Instance variable names should be all lower case
  • Words in an instance variable name should be separated by an underscore
  • Protected instance variables should begin with a single underscore
  • Private instance variables should begin with two underscores

Example:

    pyramid_giza = "pyramid of giza" # Public
    _pyramid_giza = "pyramid of giza" # Protected
    __pyramid_giza = "pyramid of giza" # Private

7. Methods

  • Method names should be all lower case
  • Words in an method name should be separated by an underscore
  • Protected method should begin with a single underscore
  • Private method should begin with two underscores underscore

Example:

    def pyramid_giza(): # Public
    def _pyramid_giza(): # Protected
    def __pyramid_giza(): # Private

8. Method Arguments

  • Instance methods should have their first argument named "self"
  • Class methods should have their first argument named "cls"
  • Static method is similar to a class method but, won't get the class object

Example:

    class PyramidGiza(object):
        def instance_method(self):
            print(f'Hello from {self.__class__.__name__}')

        @classmethod
        def class_method(cls):
            print(f'Hello from {cls.__name__}')

        @staticmethod
        def static_method():
            print(f'Hello from {PyramidGiza.static_method.__name__}')

9. Functions

  • Function names should be all lower case
  • Words in a function name should be separated by an underscore

Example:

    def pyramid_giza():

10. Constants

  • Constant names must be fully capitalized
  • Words in a constant name should be separated by an underscore

Example:

TOTAL
[or]
MAX_CAPACITY

Ref

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment