编程之美

前言

犯了大忌。

我还大一的时候，也包括那之前的岁月，是喜爱与人争论的。那时候的自己，总要弄个熟是熟非。这其实是很没有意义的事，因为并不是所有人都值得你去耗费时间，大部分人的冥顽不灵也不值得你去生气。所以我不再去为什么争辩了。

当然，上面所说的一切也仅仅是以主观角度。先决条件是“我是对的”。但无妨，做个井底之蛙总比浪费自己的生命要强许多吧。

这次我却出自己意料。也许换了新环境（当然怪不得环境），抑制力有所下降。先后两次跟同事争论“程序员该不该支持开源”和“什么是好的代码”。

对方的意思是，因为自己就是程序员，更应该保护自己的知识产权。这并非有错，但这不是支持不开源的理由吧。因为“开源”与保护知识产权没有自相矛盾。我继而说我是支持开源的，自己的代码也会上传GitHub。他说当然咯，你那些都不过是垃圾代码。

我觉得我同事也没说错，我现在写的代码跟“垃圾”二字说不定是有表亲关系。不过没关系，但倘若再过三四年情况依旧，我自然是要沮丧的。可他的话里，是不是也有“开源代码都垃圾”的意思呢？我肯定不能如此揣测，如果我这样诱导思路，同“杠精”有何区别。接受过高中数学的人应该知道：原命题只与逆否命题同真同假。

尽管计科专业，但自认为还不专业。我是年初自学Python之后才觉着编程有趣，继而坚定要走这条路。秋招拿到四个offer，最后决定现在这家公司，主要因为提供的岗位是Python研发。除去Python缩短开发周期，见效快，我偏爱它的强制缩进，以及哲学的设计思想。支不支持开源暂时不说，我写的代码垃圾我也认（事实上我来上班的这两周还没为公司写过代码）。但“什么是好代码”我一定要发表自己的言论，毕竟这是我对Python日久生情的原因。

同事的意思是：天花乱坠地使用函数式编程，让人读不懂的是为好代码。

我的观点呢我暂时不说。

Python之禅

PEP20是Python的指导准则，又名：Python之禅。在Python的交互式中输入，回车，我们可以看到如下内容：

以下是我阅读《Python 编程之美》一书的读书笔记。第四章：编写高质量代码。原想的是等读完之后再整理成一个系列，现在看会有些散乱。

盲目地保持一致是头脑简单的表现

明确胜于隐晦

如今设计一个函数，用于返回一个字典：

而更优雅的写法：

说明：设计出来的函数应该让其他开发者看得懂

松散胜于紧凑

一行尽量写一句。某些复合语句，比如列表解析，表达能力强，也允许并支持单行编写。如果相互独立的多条语句，建议分多行代码来写。

糟糕写法：

优雅写法：

说明：可读性比代码多几个字节或多几微妙的运行时间更重要。

错误也不该被默默忽略，除非你有意为之

Python中用try语句处理异常。但尽量少用except和pass略过所有异常，如：

更好的处理方式是：

或将捕获到的异常重新抛出：

面对歧义，拒绝猜想

公司的项目准备重构，就“要不要升级mongo”起了很大的争议。主要纠结点是：现在使用的mongo版本有没有批量操作。三点开会，七点结束，中间断续地争论这个问题，一共耗费了一个多小时。我师傅想当然地说有，负责数据层封装的同事根据经验判断说没有。

有没有，能不能，show code不就好了吗？大家都是IT人员，又不是口才吃饭。

在会议尾巴上，他们找到了分歧点：各自对“批量操作”的理解不同。

这里应该有一种——最好只有一种——明显的处理方法，尽管一开始那种方法并不明显，除非你是Python之父。

做好过不做，尽管不做好过“立马”做。

如果实现很难解释，那它不是个好思路；如果实现易于解释，则可能是个好点子。

以上观点私以为适用于所有编程语言（当然“除非你是Python之父”一句得抹掉），它更像是编程的核心思想。

命名空间是绝佳主意

在我学习的语言中，印象最深的应该是C++中的namespace，其他语言是否强调命名空间这一概念确实不知道也不记得了。我至少没看到太多人在Python中明确地说起。所以突然提这个概念，可能有人觉得突兀。《Python 编程之美》有这样一句话：模块的变量、函数和类都通过模块的命名空间提供给调用者。

是不是似曾相识的操作？其实就是开辟了一个module的命名空间。

非常糟糕地写法：

较好地方式：

最好地方式：

结束语

Python语言以优雅著称，强调其代码可读性强。我实在想不通一个用Python开发一年的程序员为什么会认为看不懂的代码是好代码。

算了算了，不争了。非宁静无以致远。

周二接到公司指派的任务——修改项目中代码不规范的地方。我的代码垃不垃圾呢我想同事们还不知道，谁的代码垃圾我知道。