一份两百多行的 脚本报错位置却永远停在最后一句ValueError: invalid literal for int with base 10: 我第一眼不太信是数据本身的问题。不停持续朝着上面递进翻着, 居然真的看见了一段代码, 这段代码包含读取CSV, 进行判断字段, 计算金额, 拼接结果, 记录异常这些操作, 并且全部拥挤在一个for循环之中。条件判断套了足足四层, 然而循环中间还夹着三个。这种代码平时跑得好好的一旦数据脏一点排查起来特别费劲。条件判断不复杂, 循环也不复杂, 函数同样不复杂。然而, 真正容易致使写乱的情况是, 当这三样东西混合在一起之后, 它们之间不存在边界。比如说, 拿个平常会见到的订单导入脚本来讲。CSV里有订单号, 还有用户编号, 以及商品数量和单价, 我们要把无效的数据过滤掉, 然后去算出订单的金额。很多人第一版会这么写for row in rows: if row.get(order_no): if row.get(quantity): if row.get(price): quantity int(row[quantity]) price float(row[price]) if quantity 0and price 0: total quantity * price results.append({ order_no: row[order_no], total: total })代码能运行但我一般不会让它进正式脚本。最大的问题并非是缩进显得难看, 而是失败的原因被吞没了。订单号呈现为空的状态, 数量格式出现错误, 价格小于零, 最终全部都是“没有进入 ”的情况。等到业务询问某条订单为何没有导入时, 只能再次重新运行一遍, 还要临时添加打印。条件判断最好先处理失败分支。defcheck_order(row): order_no row.get(order_no, ).strip ifnot order_no: returnFalse, 订单号为空 try: quantity int(row.get(quantity, )) price float(row.get(price, )) except (TypeError, ValueError): returnFalse, 数量或单价格式错误 if quantity 0: returnFalse, 商品数量必须大于0 if price 0: returnFalse, 商品单价必须大于0 returnTrue, { order_no: order_no, quantity: quantity, price: price }这里没有什么炫技就是把错误尽早返回。为了追寻“仅存一个”, 我着实不太乐意硬是将所有分支囊括于一个极为庞大的if之内。业务校验并非是在搞数学证明, 倘若有哪个条件没法满足, 便在那一处停下脚步, 如此一来, 后续查看代码的人省事儿不少。循环负责调度不负责处理全部业务。defload_orders(rows): passed rejected for line_no, row in enumerate(rows, start2): ok, detail check_order(row) ifnot ok: rejected.append({ line: line_no, order_no: row.get(order_no, ), reason: detail }) continue detail[amount] round( detail[quantity] * detail[price], 2 ) passed.append(detail) return passed, rejected在这里很合适。当前数据不合法记录原因然后处理下一条。但, 也绝不能够随意滥用起来。在一个循环之中, 跳转的数量若是过多, 那么所执行的路径就会转而变得过于细碎。特别是, 其前面要是还存在着计数操作、文件写入动作或者状态更新情况, 便极易出现遗漏执行的情况发生。当我着手处理循环之际, 一般而言会着重审视两个层面的要点: 其一, 本次循环所指向的目标为何其二, 究竟在何种情形之下应当即刻予以终止。假如在一批订单当中去寻觅首个金额出现异常状况的订单, 当找到之后就不存在要继续扫描的必要了。deffind_first_abnormal(orders, limit): for order in orders: if order[amount] limit: return order returnNone同设置一个变量然后进行break相比较, 这里直接进行操作显得更为简洁明了。函数已然获取到了结果那么这个函数就应当结束。根本不存在让代码去绕上一圈之后再退出的必要。还有一种情形是进行批量处理, 单条出现失败的情况不会对后续的数据造成影响。在这个时候, 将异常放置于循环的内部来处理, 而不是把整个循环给包裹住:defcalculate_amounts(orders): completed failed for order in orders: try: amount order[quantity] * order[price] completed.append({ **order, amount: round(amount, 2) }) except (KeyError, TypeError) as exc: failed.append({ order_no: order.get(order_no, ), error: str(exc) }) return completed, failed倘若将try置于for的外面, 一旦有一条数据出现错误, 那么整批任务便都会停止运行。这样的写法在测试数据当中并不显著, 然而在上线运行导入任务的时候却会令人感到非常烦恼, 前面已经处理了的数量究竟是多少、后面还剩余的数量又是多少, 全部都需要重新进行确认。函数也不是拆得越细越好。我曾撞见一个字段校验被划分成七八个子函数: 拥有一种判断是否为空之物叫做函数, 存在一个将其转为整数的叫作函数, 还有一种用以判断正数的亦是函数。其调用链眼见上去甚是“规格严整”, 然而在排查时须要来来回回跳转文件呀。函数值不值得拆我一般看它有没有独立职责。负责对数据进行校验然后进行转换, 负责对结果进行遍历进而进行收集, 这样的边界相对比较自然。至于一行大于0这种情况, 没必要特意将其包装成功能。最后把脚本入口收一下defrun_import(rows): valid_orders, invalid_rows load_orders(rows) print( f导入完成成功 {len(valid_orders)} 条 f失败 {len(invalid_rows)} 条 ) for item in invalid_rows[:10]: print( f第 {item[line]} 行失败 f{item[reason]} ) return valid_orders如今, 数据能否持续, 取决于条件判断, 下一条数据何时起始, 由循环来定夺, 函数则承担着将各异职责予以分隔的任务。三样东西单独看都简单混在一起就很考验代码习惯。碰到那种判断包住循环, 循环当中还塞着异常处理的代码, 我通常不会马上就去优化语法。首先把失败的分支给提取出来, 接着将单条的处理从循环里面拿出来。一旦代码的层级有所降低, 许多隐藏着的问题自己就会显现出来。