对待代码，就像对待情人，要用心，要写得大方，优雅。曾有人用代码量来评估编程水平，纯属扯淡。如果你的代码，能让普通人都看得懂，那必然是好的代码，如果你的代码给同行人带来迷惑，那你该为自己感到羞愧！废话一堆，见正文。
>>> import this
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!
