I have summarized some of the Python naming conventions in another article before, and it has also helped some friends. Today’s article is mainly about sharing "The Zen of Python"
Jump to historical articles:Python common naming conventions_python naming conventions_Huahuajun’s blog-CSDN blog
Check out the "The Zen of Python" method:
import this in the interpreter
After running directly, the console outputs the English version of "The Zen of Python"
Original English version:
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 be one-- and preferably only one --obvious way to do it.
Although that way may not be 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 may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Chinese translation:
Zen of Python Author: Tim Peters
Beautiful is better than ugly
Clear is better than obscure
Simplicity is better than complexity
Complex is better than messy
Flat is better than nested
Space is better than compact
Readability is important
These rules cannot be violated even under the guise of the practicality of exceptions
Don't tolerate all errors unless you know you need to
Don’t try to guess when there are multiple possibilities
Instead try to find one, preferably the only obvious solution
Although it won't be easy since you are not the father of Python
Doing it may be better than not doing it, but doing it without thinking is worse than not doing it
If you can't describe your solution to people, it's definitely not a good solution; and vice versa.
Namespaces are a wonderful idea that we should take advantage of more
Interpretation:
Python aims to write beautiful code
Beautiful code should be clear, well-named, and similar in style
Beautiful code should be concise, without complex internal implementations
If complexity is unavoidable, there should be no difficult-to-understand relationships between codes and the interface should be kept simple.
Beautiful code should be flat and not have too much nesting
Beautiful code has appropriate intervals. Don’t expect one line of code to solve the problem.
Beautiful code is readable
Catch exceptions accurately without writing except:pass style code
PS: Make good use of the ctrl+alt+L shortcut keys in PyCharm to quickly format the code and facilitate reading (everyone knows this, but some friends have not developed the habit, so hereby remind you)