Introduction to Python Code Writing Specifications
Programming specifications, also known as coding conventions, refer to the norms and guidelines followed in software development. It is a set of regulations and guidelines aimed at standardizing and unifying the writing style, format, and naming habits of code. Writing code that conforms to the specification improves readability, maintainability, and extensibility. Programming specifications are not rigid rules, but a kind of guiding norms and guidelines.
The programming specification can be clearly defined in the early stage of the project, and through team consensus and code review to ensure that every developer abides by it, so that the code style is unified, mutual understanding and modification of the code are easier, and it is easy to understand, maintain and collaborate. By following programming conventions, you can improve code readability, maintainability, security, and performance, and enhance teamwork efficiency.
The Python programming specification should follow PEP 8. PEP is the abbreviation of Python Enhancement Proposal, usually translated as "Python Enhancement Proposal". Each PEP is a technical document for the Python community to guide the development of Python in a better direction. Enhancement Proposal No. 8 is a code style guide for the Python language: PEP 8 – Style Guide for Python Code |peps.python.org
Chinese translation https://www.cnblogs.com/bymo/p/9567140.html#_label2_0
Here are some key points from the PEP8 specification:
1. Use 4 spaces for indentation and avoid using tabs ( tabs ), because different editors may interpret the width of tabs differently.
2. Try not to exceed 79 characters per line of code.
3. The definitions of top-level functions and classes are separated by two blank lines before and after, and the method definitions in the class are separated by one blank line.
4. Add spaces before and after operators, such as assignment, comparison, logical operations, etc.
5. Variable names and function names should be in lowercase, separate words with underscores, and variable names should also be in lowercase, such as, my_variable.
6. Constant names should be in all uppercase, with underscores separating words, eg WEEK_OF_MONTH.
7. The class name is named in camel case (Pascal naming), that is, the first letter of each word is capitalized, and it is not separated by underscores, such as SpringBoot.
8. Use English in the comments, the comments should be clear and clear, do not write useless comments.
9. Avoid single-character variable names, except for counters or iterators.
10. Use spaces to separate parameters and parameter lists, but do not put spaces between the function name and the opening parenthesis.
11. Use single quotes instead of double quotes whenever possible in your code, unless the string contains single quotes.
12. When importing modules, standard library modules should be placed before other modules, and each module should be separated by a blank line. Each import module statement should be on its own line.
13. For modules, classes, and functions, use documentation strings (docstring) to provide descriptions of their functions, parameters, return values, etc. Docstrings should be placed below the definition and enclosed in triple quotes.