Shulou(Shulou.com)06/02 Report--

Today, I will talk to you about how to write high-quality Python programs, many people may not know much about it. In order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

How to write High quality python programs

Code specification

First of all, read the following two specifications and understand them in depth.

The official Python coding style recommended by the Python community: PEP8 Chinese version

Google SoC recommended Python coding style: Google Python Style Guide Chinese version

Writing standard code is a step to writing high-quality code and helps to develop careful habits.

In order to develop the habit of standardizing the writing of code, you can install flake8, which can not only check whether the code style is in line with the official recommendation (PEP8), but also find out potential pitfalls (using Pyflakes for parsing), what's more, it can detect that some of your functions are too complex (code cyclical complexity), and even worse, you can set up git commit before you must pass these checks.

Of course, the specific operation needs to be customized according to your own project, for example, you can ignore E501dyW293.

Blank project template

A good beginning is half done, so writing python code starts with pyempty.

Take a look at those classic projects on github, web.py,flask, pep8, their project catalogs are very standardized, comprehensive reference to the characteristics of some projects, I wrote this pyempty project.

1.README.md here write your project profile, quick start and other information, although distutils requires that this file does not have a suffix, but on github if the suffix is .md, it can be directly converted to html display.

2.ChangeLog.txt this file stores the change information of various versions of the program, and also has a certain format. Refer to web.py 's ChangeLog.txt.

3.LICENES.txt stores the protocols used by your project here. Do not write your own protocols.

4.requirements.txt if your project needs to rely on other python third-party libraries, write it out here one by one, and maybe you can install it automatically when you pip install.

5.setup.py installation script, described in more detail later

6.docs stores your project documents, such as outline design, detailed design, maintenance documents, pydoc automatically generated documents, etc. It is highly recommended that you use MarkDown format to write documents.

The 7.src directory stores the main code of the project module. Try not to put the module directory directly into the root directory. The module code directory can be specified in setup.py.

8.tests this directory holds all unit tests, performance test scripts, and unit test files make sure they are prefixed with test_, so that distutils automatically packages these files, and these tests can be executed directly with python-m unittest discover-s. /-p 'test_*.py'-v

Unit testing

Martin Fowler: "you shouldn't write a program until you don't know how to test the code. Once you've finished the program, the test code should be done. Unless the test is successful, you can't think that you've written a program that works."

There are many reasons not to write unit tests, which boils down to laziness, although the code says:

Most studies have found that testing is less expensive than testing. A study by the NASA Software Engineering Lab found that reading code detected about 80 per cent more defects per hour than testing (Basili and Selby 1987). Later, a study by IBM found that an error found by inspection takes only 3.5 working hours, while testing takes 15-25 working hours (Kaplan 1995).

But unit testing is the strongest evidence to convince others that your code is of high quality.

All right, please read in detail:

In-depth python3.0: unit testing-2.x also applies

Unit testing framework incomplete Chinese version

Document

Agile development does not advocate no documentation, no documentation, no inheritance and accumulation, rotation or newcomers will encounter a lot of trouble to take over the task, so I decided to write at least the following documents for each project:

1.nalysis.model.md summary design document, different from the README.md file, this document should be written before the project development, what functions the project has, probably divided into several modules and other project overview information.

2.design.model.md detailed design documents, do not need to be too detailed, at least what the project depends on, who depends on the project, important algorithm flow description, the overall structure of the code, etc.

3.maintain.md maintenance documents, which I think is the most important, which logs are recorded by your service, which business metrics need to be monitored, how to restart, what configuration items are available, etc. Without these things, your project is very difficult to operate and maintain.

The above documents are project-wide and are not suitable for writing in docstring or gaze, so there should be separate documents.

Packing

Python has a special module packaging system distutils, which you can use to package and distribute your code to Pypi, so that anyone can install your module with pip or easy_install.

If you are developing an internal project, you can also use mypypi to build a private pypi, and then update the large version of the project to the internal pypi, configuration managers and operators can easily pull the replacement code from pypi to the test environment or production environment.

When you release a large version, you need to name the version and write ChangeList. You can refer to the relevant chapters of Git Pro and mainly remember the following commands.

Git tag-a v0.1-m'my test tag' # name the major version and Tag git describe master # the minor version. Git will return a string consisting of three parts: the last calibrated version number, plus the number of submissions since that calibration, plus a paragraph with the SHA- 1 value git shortlog-- no-merges master-- not v0.1 # to generate the version brief, ChangeList

Python has its own packaging mechanism, so generally do not use the git archive command.

Of course, pypi management is more appropriate for large version management. Many companies, such as small bug fix and emergency launch, use git to pull code updates directly from the production environment, because git,svn and other companies can easily undo a certain update and roll back to a certain location.

After reading the above, do you have any further understanding of how to write high-quality Python programs? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.