前言
犯了大忌。
我还大一的时候,也包括那之前的岁月,是喜爱与人争论的。那时候的自己,总要弄个熟是熟非。这其实是很没有意义的事,因为并不是所有人都值得你去耗费时间,大部分人的冥顽不灵也不值得你去生气。所以我不再去为什么争辩了。
当然,上面所说的一切也仅仅是以主观角度。先决条件是“我是对的”。但无妨,做个井底之蛙总比浪费自己的生命要强许多吧。
这次我却出自己意料。也许换了新环境(当然怪不得环境),抑制力有所下降。先后两次跟同事争论“程序员该不该支持开源”和“什么是好的代码”。
对方的意思是,因为自己就是程序员,更应该保护自己的知识产权。这并非有错,但这不是支持不开源的理由吧。因为“开源”与保护知识产权没有自相矛盾。我继而说我是支持开源的,自己的代码也会上传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开发一年的程序员为什么会认为看不懂的代码是好代码。
算了算了,不争了。非宁静无以致远。
周二接到公司指派的任务——修改项目中代码不规范的地方。我的代码垃不垃圾呢我想同事们还不知道,谁的代码垃圾我知道。
领取专属 10元无门槛券
私享最新 技术干货