Encoding declaration

Default is not set to ASCII, can be set to

1

# coding=<encoding name>

or

1
2

#!/usr/bin/python
# -*- coding: <encoding name> -*-

or

1
2

#!/usr/bin/python
# coding: utf-8

Code layout

  • Four spaces per indentation, tabs are not recommended, and mixed tabs and spaces are not recommended
  • A single line can be up to 79 characters long, backslashes can be used for line breaks, and parentheses are preferred
  • Two blank lines between classes and functions of the same level, and one blank line between methods in a class
  • Module writing order: module description and docstring, import, globals, constants, and others; import is arranged in the order of standard, third-party, and self-written, and it is not recommended to write in one line
  • ​​Add a space on the left and right of the operator, omit spaces on the left and right of the assignment operator used by the default function parameter, and do not add spaces before various right brackets;
  • Comments must be written in English, preferably complete sentences, with the first letter capitalized, and a terminator followed by two spaces to start the next sentence. If it is a phrase, the terminator can be omitted.
  • Write docstrings for all shared modules, functions, classes, and methods; non-shared ones are not necessary, but comments can be written (on the next line after def)

Naming standards

  • Try to use lowercase letters ‘l’, uppercase letters ‘O’ and other easily confused letters alone.
  • Keep module names as short as possible, use all lowercase letters, and use underscores.
  • Keep package names as short as possible, use all lowercase letters, and do not use underscores.
  • Use CapWords for class naming, and _CapWords for classes used within the module.
  • Use CapWords+Error suffix for exception naming.
  • Global variables should be valid only within the module as much as possible, similar to static in C language. There are two ways to implement this: one is the all mechanism; the other is to prefix an underscore.
  • Use all lowercase letters for function naming, and underscores can be used.
  • Constant names are all capitalized, and underscores are allowed.
  • Class attributes (methods and variables) are all lowercase, and underscores are allowed.
  • Class attributes have three scopes: public, non-public, and subclass API, which can be understood as public, private, and protected in C++. Non-public attributes are prefixed with an underscore.
  • If a class attribute conflicts with a keyword name, add an underscore to the suffix. Try not to use abbreviations or other methods.
  • To avoid naming conflicts with subclass attributes, prefix some class attributes with two underscores. For example: __a is declared in class Foo, and can only be accessed through Foo._Foo__a to avoid ambiguity. If the subclass is also called Foo, there is nothing you can do.
  • The first parameter of the class method must be self, and the first parameter of the static method must be cls

Code checking tool

1

pip install flake8

After successfully installing flake8, open VScode, File->Preferences->User Settings, and enter “python.linting.flake8Enabled”: true in the settings.json file

Automatic formatting tool

1

pip install yapf

After successfully installing yapf, open VScode, File->Preferences->User Settings, and enter “python.formatting.provider”: “yapf” in the settings.json file

Project development notes:

When starting a blank project, you need to pay attention to the following points:

  • README.md Write your project introduction, quick start and other information here. Although distutils requires this file to have no suffix, if the suffix is ​​.md on github, it can be directly converted to html for display.
  • ChangeLog.txt This file stores the change information of each version of the program. It also has a certain format. Please refer to ChangeLog.txt of web.py
  • LICENES.txt This is where you store the agreement used by your project. Do not write your own agreement.
  • requirements.txt If your project needs to rely on other third-party python libraries, write them one by one here, and pip install may automatically install them for you
  • setup.py installation script, which will be described in detail later
  • docs stores your project documents, such as outline design, detailed design, maintenance documents, documents automatically generated by pydoc, etc. It is strongly recommended that you use MarkDown format to write documents
  • src This directory stores the main code of the project module. Try not to put the module directory directly in the root directory. The module code directory can be specified in setup.py
  • tests This directory stores all unit tests and performance test scripts. Make sure that the unit test files are prefixed with test_, so that distutils will automatically package these files, and use python -m unittest discover -s ./ -p ’test_*.py’ -v to directly execute these tests

Reference:

https://www.python.org/dev/peps/pep-0008/ https://wiki.woodpecker.org.cn/moin/PythonCodingRule