1.5 Python coding style PEP8 смотреть онлайн

Python coding style
• PEP 8 has emerged as the style guide that most projects adhere to; it promotes a very readable and eye-pleasing coding style. • Every Python developer should read it at some point. • PEP stands for Python Enhancement Proposals.
https://www.python.org/dev/peps/pep-0008

PEP 8
• Most languages can be written in different styles; some are more readable than others. Making it easy for others to read your code is always a good idea. Adopt nice simple coding style to help others. • Python has simple style and the most important points are discussed in this session.
https://docs.python.org/3.7/tutorial/controlflow.html#intermezzo-coding-style
Code Lay-out
• Indentation • Wrap lines • Blank Lines • Comments • Docstrings • Tabs or Spaces?
• Tabs or Spaces? • Line Break • Source File Encoding • Imports • Module Level Dunder Names
Indentation
• Use 4-space indentation, and no tabs. Tab in some editors (ex. Notepad++) have 4 space tab. • 4 spaces are a good compromise between small indentation (allows greater nesting depth) and large indentation (easier to read).
Wrap lines (Max line length)
• Wrap lines so that they don’t exceed 79 characters. • This helps users with small displays and makes it possible to have several code files side-by-side on larger displays. • Python is free language. You can break line any where.

Blank lines for readability
• Use blank lines to separate functions and classes, and larger blocks of code inside functions.
Comments
• Add comments for clear understanding to benefit fellow programmers to quickly catchup. Python has two ways to annotate Python code. • Single-line comments begin with the hash character ("#") and are terminated by the end of line. • Multi line comments are achieved by inserting a multi-line string with """ as the delimiter on each end.
Use docstrings
• Docstrings (documentation strings): strings that are located alone without assignment as the first indented line within a module, class, method or function, automatically set their contents as an attribute named __doc__.
docstrings
Spaces
• Use spaces around operators and after commas, but not directly inside bracketing constructs: a = f(1, 2) + g(3, 4).
Naming classes and functions
Name your classes and functions consistently; • Classes naming convention: camelCase • functions and methods: lower_case_with_underscores • camelCase is named after the camel humps, is the practice of writing phrases with middle of the phrase begins with a capital letter. Common examples include "iPhone" and "eBay".
Encode in UTF-8
Don’t use fancy encodings if your code is meant to be used in collaborated/ international environments. Python’s default, UTF-8, or even plain ASCII work best in any case.
Don’t use non-ASCII
• Don’t use non-ASCII characters in identifiers when people speaking different languages are required to read or maintain the code.
Naming Conventions – descriptive
Prescriptive: Naming Conventions – Names to Avoid – ASCII Compatibility – Package and Module Names – Class Names – Type Variable Names – Exception Names – Global Variable Names – Function and Variable Names – Function and Method Arguments – Method Names and Instance Variables – Constants – Designing for Inheritance – And more…
Function Annotations
Annotations are stored in the __annotations__ attribute of the function as a dictionary and have no effect on any other part of the function. Function annotations are defined in PEP 3107.
https://www.python.org/dev/peps/pep-3107/
Module Level Dunder Names
• Module level "dunders" (i.e. names with two leading and two trailing underscores) such as __all__, __author__, __version__, etc. should be placed after the module docstring but before any import statements except from __future__ imports. • Python mandates that future-imports must appear in the module before any other code except docstrings: