The Zen of Python----The Zen of Python

First, the Zen of Python

in the Python shell, enterimport this, it will show Tim Peters'sThe Zen of Python:

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
readability counts.
Special cases aren ' t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
unless explicitly silenced.
in the face of ambiguity, refuse the temptation to guess.
there should is one--and preferably only one--obvious the-do it.
Although that is obvious at first unless you ' re Dutch.
Now is better than never.
Although never is often better than *right* now.
If The implementation is hard to explain, it's a bad idea.
If The implementation is easy to explain, it could be a good idea.
namespaces is one honking great idea – let's do more than those!

Translate as follows:

beauty is better than ugliness (Python aims to write graceful code)
clarity is better than obscure (graceful code should be clear, naming specification, style similar)
simplicity is better than complexity (graceful code should be concise, not complex internal implementations)
complexity is better than clutter (if complexity is unavoidable, there is no hard-to-understand relationship between the code, keep the interface simple)
flattening is better than nesting (graceful code should be flat, not too much nesting)
The interval is better than the compact (graceful code has the appropriate interval, do not expect a line of code to solve the problem)
readability is important (graceful code is readable)
even in the name of the practicality of the special case, the rules must not be violated (these rules are paramount)
do not tolerate all errors unless you are sure you need to (catch exceptions accurately, do not write Except:pass-style code)
when there are many possibilities, don't try to guess
instead, try to find one, preferably the only obvious solution (if unsure, use the brute-lifting method)
Although this is not easy, because you are not the father of Python (here Dutch refers to Guido)
It may be better not to do it , but it's better not to do it without thinking about it (before you do it)
If you can't describe your plan to someone, it's certainly not a good plan; and vice versa (Program evaluation criteria)
namespaces are a great idea and we should use them (advocacy and calling).

Second, Writing Pythonic Code

Avoid deterioration of code

• Avoid using case-by-case to distinguish different objects;

• Avoid the use of confusing names, variable names should be consistent with the problem domain being solved;

• Don't be afraid of long variable names;

Add appropriate comments to your code

• Line annotations only annotate complex operations, algorithms, difficult-to-understand techniques, or code that is not readily apparent;

• Note and code to separate a certain distance, whether it is a line of comments or block comments;

• Add a document comment to externally accessible functions and methods (whether simple or not), note to clearly describe the functionality of the method, and describe the parameters, return values, and possible exceptions, so that the external callers can use the docstring only if they see them;

• Recommended in the file header contains the Copyright Declaration, module description, etc.;

• Comments should be used to explain the function of the code, the reason, and the idea that the code itself should not be interpreted;

• The code that is no longer needed should be deleted instead of commented out;

Add empty Exercise code layout more elegant and reasonable

• After a set of code expresses a complete idea, it should be spaced with blank lines, it is recommended to empty two lines between the function definition or the class definition, the empty line between the class definition and the first method, or where the semantic separation is required, and the empty row is inserted on the basis of the intrinsic connection between the code;

• As far as possible to ensure the easy understanding of the upper and lower Wen, is usually the caller on the top, the callee under;

• Avoid too long lines of code, preferably not more than 80 characters per line;

• Do not use extra spaces in order to maintain horizontal alignment;

Several principles for writing functions

• function design should be as short as possible, nesting level should not be too deep;

• function declaration should be reasonable, simple, easy to use, function name should be able to correctly reflect function general function, parameter design should be concise and clear, the number of parameters should not be too much;

• The design of function parameters should consider backward compatibility;

• A function only does one thing, as far as possible to ensure the consistency of function statement granularity;

Centralize constants into one file

Python does not provide a direct way to define constants, and there are generally two ways to use constants;

• By naming the style to remind the user that the meaning of the variable represents a constant, the normal volume of all letters capitalized, with an underscore to connect each word, such as max_number,totle, etc.;

• By customizing the class to implement the constant function, the constants required to comply with two points, first, the name must be all uppercase, the second is the value once the binding can not be modified;

The Zen of Python----The Zen of Python