The Zen of Python
April 30, 2007 § Leave a comment
Here is the excerpt of the Zen of Python:
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!
This might come across as a joke first time, but I found it more and more relevant to agile programming (& my coding style). And, totally applicable to different programming languages.
Now, let’s talk about simplicity and readability:
For example, in the JAVA world I keep finding myself swimming around Interface classes which only be used once. Or to be exact, this type of relationship: Interface -> Yet another Interface -> Yet one more Interface -> Abstract Class -> Concrete Class.
Obviously that drives me mad. This type of codes is clearly complex, whether such abstraction is intended or not that’s different story. But, in short, overly complex and disturb readability. Especially in debug mode. Imagine gazillion lines of stack dump, yeah…. you know what I’m talking about.
Another example, which one you prefer?
- Having polymorphisms of Entity Beans, each of the methods in them doing things slightly different…
- Or have a general ORM class, capable of handling all of those methods? (Of course in such case, you need to define the methods more carefully)
Obviously, 50% of earth’s developers prefer no. 1 and the rest prefer no.2. Either way would work, but
no.1. would have a lot more verbose stack dump. Depending on what kind of developers you are, too much verbosity might hurt your eyes.
no.2, if implemented wrongly, might hurt your eyes as well. But once implemented correctly, you always know that table_object.insert() always perform the same way regardless what kind of table_object you are talking about.
For people who have passion in building a product, getting it done as simple as possible is definitely the better approach. Thus, the Zen of Python would apply beautifully.
For people who work for big corporations, with zillions of legacy code and funky scalability… The Zen of Python might fail to guide you miserably.
In short, read the Zen… think about it… sleep over it… and try to apply it given your context. Who knows, you might have an enlightenment.