码迷,mamicode.com
首页 > 编程语言 > 详细

Python 工匠:编写条件分支代码的技巧

时间:2018-10-05 21:11:06      阅读:170      评论:0      收藏:0      [点我收藏+]

标签:魔法方法   封装   else   否则   逻辑运算   col   限制   font   代码块   

 序言

编写条件分支代码是编码过程中不可或缺的一部分。 如果用道路来做比喻,现实世界中的代码从来都不是一条笔直的高速公路,而更像是由无数个岔路口组成的某个市区地图。我们编码者就像是驾驶员,需要告诉我们的程序,下个路口需要往左还是往右。 编写优秀的条件分支代码非常重要,因为糟糕、复杂的分支处理非常容易让人困惑,从而降低代码质量。所以,这篇文章将会种重点谈谈在 Python 中编写分支代码应该注意的地方。

Python 里的分支代码

Python 支持最为常见的 if/else 条件分支语句,不过它缺少在其他编程语言中常见的 switch/case 语句。 除此之外,Python 还为 for/while 循环以及 try/except 语句提供了 else 分支,在一些特殊的场景下,它们可以大显身手。 下面我会从 最佳实践常见技巧常见陷阱 三个方面讲一下如果编写优秀的条件分支代码。

加vx:tanzhouyiwan或qq群813622576免费领取学习资料

最佳实践

1. 避免多层分支嵌套

如果这篇文章只能删减成一句话就结束,那么那句话一定是“要竭尽所能的避免分支嵌套”。 过深的分支嵌套是很多编程新手最容易犯的错误之一。假如有一位新手 JavaScript 程序员写了很多层分支嵌套,那么你可能会看到一层又一层的大括号:if { if { if { ... }}}。俗称“嵌套 if 地狱(Nested If Statement Hell)”。 但是因为 Python 使用了缩进来代替 {},所以过深的嵌套分支会产生比其他语言下更为严重的后果。比如过多的缩进层次很容易就会让代码超过 PEP8 中规定的每行字数限制。让我们看看这段代码:技术分享图片

上面这段代码最大的问题,就是过于直接翻译了原始的条件分支要求,导致短短十几行代码包含了有三层嵌套分支。 这样的代码可读性和维护性都很差。不过我们可以用一个很简单的技巧:“提前结束” 来优化这段代码:

技术分享图片

“提前结束”指:在函数内使用 return 或 raise 等语句提前在分支内结束函数。比如,在新的 buy_fruit 函数里,当分支条件不满足时,我们直接抛出异常,结束这段这代码分支。这样的代码没有嵌套分支,更直接也更易读。

2. 封装那些过于复杂的逻辑判断

如果条件分支里的表达式过于复杂,出现了太多的 not/and/or,那么这段代码的可读性就会大打折扣,比如下面这段代码:

技术分享图片

对于这样的代码,我们可以考虑将具体的分支逻辑封装成函数或者方法,来达到简化代码的目的:

技术分享图片

事实上,将代码改写后,之前的注释文字其实也可以去掉了。因为后面这段代码已经达到了自说明的目的。至于具体的 什么样的用户满足活动条件? 这种问题,就应由具体的 match_activity_condition() 方法来回答了。

Hint: 恰当的封装不光直接改善了代码的可读性,事实上,如果上面的活动判断逻辑在代码中出现了不止一次的话,封装更是必须的。不然重复代码会极大的破坏这段逻辑的可维护性。

3. 留意不同分支下的重复代码

重复代码是代码质量的天敌,而条件分支语句又非常容易成为重复代码的重灾区。所以,当我们编写条件分支语句时,需要特别留意,不要生产不必要的重复代码。 让我们看下这个例子:

技术分享图片

在上面的代码中,我们可以一眼看出,在不同的分支下,程序调用了不同的函数,做了不一样的事情。但是,因为那些重复代码的存在,我们却很难简单的区分出,二者的不同点到底在哪。 其实,得益于 Python 的动态特性,我们可以简单的改写一下上面的代码,让可读性可以得到显著的提升:

技术分享图片

当你编写分支代码时,请额外关注由分支产生的重复代码块,如果可以简单的消灭它们,那就不要迟疑。

4. 谨慎使用三元表达式

三元表达式是 Python 2.5 版本后才支持的语法。在那之前,Python 社区一度认为三元表达式没有必要,我们需要使用 x and a or b 的方式来模拟它。[注] 事实是,在很多情况下,使用普通的 if/else 语句的代码可读性确实更好。盲目追求三元表达式很容易诱惑你写出复杂、可读性差的代码。 所以,请记得只用三元表达式处理简单的逻辑分支。

技术分享图片

对于绝大多数情况,还是使用普通的 if/else 语句吧。

常见技巧

1. 使用“德摩根定律”

在做分支判断时,我们有时候会写成这样的代码:

技术分享图片

第一眼看到代码时,是不是需要思考一会才能理解它想干嘛?这是因为上面的逻辑表达式里面出现了 2 个 not和 1 个 or。而我们人类恰好不擅长处理过多的“否定”以及“或”这种逻辑关系。 这个时候,就该 德摩根定律 出场了。通俗的说,德摩根定律就是 not A or not B 等价于 not (A and B)。通过这样的转换,上面的代码可以改写成这样:

技术分享图片

怎么样,代码是不是易读了很多?记住德摩根定律,很多时候它对于简化条件分支里的代码逻辑非常有用。

2. 自定义对象的“布尔真假”

我们常说,在 Python 里,“万物皆对象”。其实,不光“万物皆对象”,我们还可以利用很多魔法方法(文档中称为:user-defined method,来自定义对象的各种行为。我们可以用很多在别的语言里面无法做到、有些魔法的方式来影响代码的执行。 比如,Python 的所有对象都有自己的“布尔真假”:

  • 布尔值为假的对象:None0False[](){}set()frozenset(), … …
  • 布尔值为真的对象:非 0 的数值、True,非空的序列、元组,普通的用户类实例,… …

通过内建函数 bool(),你可以很方便的查看某个对象的布尔真假。而 Python 进行条件分支判断时用到的也是这个值:

技术分享图片

重点来了,虽然所有用户类实例的布尔值都是真。但是 Python 提供了改变这个行为的办法:自定义类的 __bool__ 魔法方法 (在 Python 2.X 版本中为 __nonzero__。当类定义了 __bool__ 方法后,它的返回值将会被当作类实例的布尔值。 另外,__bool__ 不是影响实例布尔真假的唯一方法。如果类没有定义 __bool__ 方法,Python 还会尝试调用 __len__ 方法(也就是对任何序列对象调用 len 函数),通过结果是否为 0 判断实例真假。 那么这个特性有什么用呢?看看下面这段代码:

技术分享图片

上面的代码里,判断 UserCollection 是否有内容时用到了 users._users 的长度。其实,通过为 UserCollection 添加 __len__ 魔法方法,上面的分支可以变得更简单:

 

Python 工匠:编写条件分支代码的技巧

标签:魔法方法   封装   else   否则   逻辑运算   col   限制   font   代码块   

原文地址:https://www.cnblogs.com/zxcv1234/p/9745698.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!