Push Ifs Up and Fors Down：代码优化的代数法则
Push Ifs Up and Fors Down: The Idiom, Its Algebra, and Its Limits
源自 TigerBeetle 的编程启发式原则“Push Ifs Up and Fors Down”揭示了提升代码清晰度与性能的核心逻辑。该法则建议将条件分支（if）向上推至调用者，让函数专注于无分支的核心逻辑；同时将循环（for）向下推至批量处理层，以利用向量化执行。文章深入探讨了这一原则在 SQL 查询优化（如投影提前、连接推迟）以及函数式编程范畴论中的映射，指出通过类型系统（如用 Walrus 替代 Option<Walrus>）记录前置条件，能有效减少无效计算。这不仅是一种编码习惯，更是基于代数定律的系统性重构策略。
关键在于决策点的位置，而非有多少数据流向下游。
HN 评论区
56- hatthew
我们是在从 CS（算法优化）的角度讨论，还是从 SE（代码设计）的角度？
从 SE 的角度来看，写一个 flatmap 函数，显式处理 Collection<Optional<Walrus>>。具体实现不重要。如果你的语言或框架已经有了兼容的 flatmap 函数，就写一个单一的 frobnicate(Optional<Walrus>) 函数，返回 flatmap(frobnicate) 丢弃它们所需的任何值。
从 CS 的角度来看，将 Collection<Optional<Walrus>> 过滤为 Collection<Walrus> 可能并不是个好主意。如果你的集合很小，什么都无所谓。如果集合很大，你可能不想花时间创建它的新副本。如果你的 filter 只是返回一个视图而不是硬拷贝，那么就没有优化收益，你应该直接从 SE 的角度做最合理的事。如果 frobnicate 很便宜，那么无论何时执行 frobnicate，你反正都要支付分支预测失败的代价；如果 frobnicate 更昂贵，那你大概应该并行化，让每个线程处理 Optional 的解包。无论如何，你可能都不想把时间花在创建副本上。
这些都是基于假设的泛化，肯定有很多例外，但总的来说，我没看出这里有什么强有力的论点。如果优化很重要，就根据你自己的性能分析来优化；如果优化不重要，就根据什么功能最……
- socializer
我始终对 LLM 的能力印象深刻：它们能把琐碎的想法变成冗长晦涩的博客文章，还加上不必要的类比。
- rtpg
我一直相信相反的观点：把条件判断深入到代码内部，这样更高层的控制流就能保持规整。
但我认为，让代码避免 bug 的更大哲学在于：处理数据时，你主要做两件事：
- 分发（distribution）
- 决策（deciding）
而你要避免把分发和决策混在同一处。
“分发”可以是 for 循环，也可以是根据某个键将数据拆分成 N 个不同的桶。
“决策”则是更仔细地查看数据以做出某些决定（比如“这是大客户还是小客户”）。
分发通常涉及决策，但如果你把它们混在一起，就会模糊你的决策点。把它们分开，事情就“显然”是对的或“显然”是错的。当然性能是另一个话题，但在实践中，大多数情况都达不到需要纠结的规模。
by_category = defaultdict(list)
for d in data:
by_category[category(d)].append(d)
for category, per_category_data in by_category.items():
do_thing(category, per_category_data)
我真的很看重那些能让错误显而易见，或者至少让错误更难藏身的代码模式。不过，有些模式在这个模型下确实不太容易描述。
（我确实赞同“在处理集合时保持词汇一致性”这条原则，只是我发现顶层条件判断的使用往往会很快让你陷入“……为什么这个方法 n……”的困境。
- ivanjermakov
省点时间，直接读原文吧：https://matklad.github.io/2023/11/15/push-ifs-up-and-fors-do...
- ninalanyon
我这么做了很多年。当然不是每次都做，但在能让代码更易理解和维护的地方我会这么做。
速度几乎从来不是原因。