Python conventions (Zen of python)

image by Tina Leggio

Maybe you didn’t knew it but, python has its own philosophy in the way that the code is written, this phylosiphy its a little extensive but it certainly help us to be more productive.

Here is the complet python pilosophy, wich its called Zen :

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!

See the original on the official site

A bref explanation

Beutifull its a combination of explicit, simple, sparse and complex code that its easy to read, that is actually the mean purpuse of this, make the code easy to understand and read, if we can’t understand our own code, nobody will do it and it can’t be reusable (readability counts).

Here is a deeper explanation of explicit, simple, sparse and flat.

Explicit: Provides a clear explanation of what your program its doing.

Simple: Provides clarity when the code its readed.

Complex: Means that its better to use a simple but complex solution of 4 lines of code than one that have 15 but its simpler.

Sparse: Use a few lines of code instead of a bunch of them.

Although that way may not be obvious at first unless you're Dutch:

Means that you can find a way to solve a problem, but commonly the first one its not going to be the best one.

Now is better than never.

If you are starting to code, don’t spend to much time thinking in the perfect way to solve your problem, code something instead and think on improve it.

Although never is often better than *right* now.

Nevertheless, think a little bit and don’t just do it without knowing what are you doing.

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.

Remember that this code should be easy to read, if its complicated (hard to read), it is not a good idea, however if its too easy to understand may not be the most efficient way.

Namespaces are one honking great idea -- let's do more of those!

Well, basically you should use namespaces…

#tc01014