There is no issue on having complex systems if they are made of simple parts, well splitted and with a proper context on each individual parts. The simpler the better as they could be tested easier and get modulazed easily. The best approach to develop systems is to make small and simple part of the them. Return hypotenuse Simple is better than complex Hypotenuse = math.sqrt(a_side**2 + b_side**2) Return math.sqrt(a**2 + b**2) def pythagoras_theorem(a_side, b_side):
#RTHE ZEN OF PYTHON CODE#
Sometimes, convering implicit code into explicit code, is as simple as adding some proper names to the variables used on a function or a method. The explicit code is the one that doesn’t require some further understanding of the code behind what is shown on the code, it is clean, simple and more expresive that the implicit version. The sense of beauty on the code is trained over the experience so it is normal to get that sense over the time. So it is recommended that every time you read Python, you have the feeling that the code is beautiful, otherwise try to rewrite it in a more beautiful way. Namespaces are one honking great idea - let's do more of those!Įven if usually the beautiful or ugliness of a something is subjective, when reading code, usually we use expressions like it stinks or doesn’t look right, that are similar to say that code is ugly. If the implementation is easy to explain, it may be a good idea. If the implementation is hard to explain, it's a bad idea.
There should be one- and preferably only one -obvious way to do it.Īlthough that way may not be obvious at first unless you're Dutch.Īlthough never is often better than *right* now. In the face of ambiguity, refuse the temptation to guess. Special cases aren't special enough to break the rules.
#RTHE ZEN OF PYTHON HOW TO#
The rules are written into the PEP 20 and can be found here: but on this post you will find them and examples of how to apply them.Įvery Python interpreter has an easy way to pull the zen of Python, just typing import this > import this There are only 19 rules to build code in Python and to unify the criteria on which decisions should be taken in case of doubts. 3.1 Python PEP 8 – How to style correctly your Python code.1.19 Namespaces are one honking great idea - let’s do more of those!.1.18 If the implementation is easy to explain, it may be a good idea.1.17 If the implementation is hard to explain, it’s a bad idea.1.16 Although never is often better than right now.1.14 Although that way may not be obvious at first unless you’re Dutch.1.13 There should be one– and preferably only one –obvious way to do it.1.12 In the face of ambiguity, refuse the temptation to guess.
0 kommentar(er)
