很多程序员写代码的时候都会遇到这种情况：一个判断条件到底该放在函数里面还是外面？循环里是不是可以加个 if？这些看起来无关紧要的小选择，实际会影响代码的清晰度、性能。最近，一位热爱简单代码和编程语言的程序员 Alex Kladov 在博客上分享了两条简单但特别实用的经验法则，引发不少开发者的注意。其表示：“把 if 往上提，把 for 往下放（Push Ifs Up, Push Fors Down）”。这会对提升代码质量有哪些作用，我们不妨通过本文一起来看看。摘要：很多程序员写代码的时候都会遇到这种情况：一个判断条件到底该放在函数里面还是外面？循环里是不是可以加个 if？这些看起来无关紧要的小选择，实际会影响代码的清晰度、性能。最近，一位热爱简单代码和编程语言的程序员 Alex Kladov 在博客上分享了两条简单但特别
作者 | Alex Kladov 翻译 | 苏宓
出品 | CSDN（ID：CSDNnews）
关于两条相关经验法则的简短说明。
把 If 条件往上推
如果函数内部有 if 条件判断，可以考虑是否能把它移到调用者那里：
// 好的写法fn frobnicate(walrus: Walrus) { ...}// 不好的写法fn frobnicate(walrus: Option) { let walrus = match walrus { Some(it) => it, None => return, }; ...}就像上面举的例子一样，函数里经常会有“前置条件”的检查——比如你传进来的参数是不是有效、是不是空之类的。很多时候，程序员会在函数内部去检查这些情况，如果不符合就什么都不做。但更好的做法，其实是把这些判断提前，在调用这个函数之前就处理好。这样一来，函数本身就可以更专注地完成它的核心工作，不用管太多额外的事。
为什么要这么做？有两个原因：
首先，如果每个函数都自己检查一次条件，那整个程序里可能会有很多重复判断，既费事又容易出错。把判断提前处理好，可以让代码整体更简洁高效。
其次，if 语句（也就是“如果……就……”）本身就是让程序变复杂的东西。判断多了，程序流程就绕了，Bug 也容易藏在里面。所以与其到处乱插 if，不如集中放在一个地方处理——比如放在主函数里统一决定怎么走，然后把具体的执行任务交给其他小函数去做，这样结构更清晰，出错的概率也更低。
而且，如果所有的判断都集中在一个地方，程序员在看代码的时候也能更容易发现有没有重复判断，或者根本不会被执行的“死代码”。比如：
fn f { if foo && bar { if foo { } else { } }}fn g { if foo && bar { h }}fn h { if foo { } else { }}对于 f 来说，更容易看出无用分支，而分散在 g 和 h 的组合里不容易发现。
这里还有一个相关的模式，叫做“dissolving enum”重构。有时候代码会长这样：
enum E { Foo(i32), Bar(String),}fn main { let e = f; g(e)}fn f -> E { if condition { E::Foo(x) } else { E::Bar(y) }}fn g(e: E) { match e { E::Foo(x) => foo(x), E::Bar(y) => bar(y) }}这里有两处分支，通过往上提，可以发现它们其实是同一个条件被重复了三次（第三次变成了数据结构）：
fn main { if condition { foo(x) } else { bar(y) }}把 For 循环往下推这条建议来自“面向数据”的编程思想。简单说就是：少就是少，多就是多。现实中的程序，大多数时候都不是在处理一个东西，而是一大批东西。特别是在那些对性能要求高的关键部分（也叫“热点路径”），几乎总是在同时处理很多个对象——正是因为数量多，这部分代码才会“热”。
所以，一个常见的好习惯是：从一开始就把“批量处理”当成主要方式，而不是只想着一个个地处理。如果真的需要处理单个对象，那就把它当成“批量里的一个特例”来对待。这样做，不光能让程序结构更清晰，还能为后面提升性能打下基础。比如：
// 好的写法frobnicate_batch(walruses)// 不好的写法for walrus in walruses { frobnicate(walrus)}这样做最主要的好处是性能，尤其在极端情况下非常明显。
如果有一整批数据可以一起处理，就能摊销启动成本，还能灵活调整处理顺序。实际上，你甚至不必按特定顺序处理实体，可以先对所有实体的某个字段统一处理，再处理其他字段，利用向量化或结构化数组技巧。
一个有趣的例子是基于 FFT 的多项式乘法：在一堆点上同时计算多项式，比一个点一个点计算要快得多！
如果 if 往上推，for 循环往下推，两条规则还能组合使用：
// 好的写法if condition { for walrus in walruses { walrus.frobnicate }} else { walrus.transmogrify }}// 不好的写法 if condition { walrus.frobnicate } else { walrus.transmogrify }}好的写法避免了在循环内部反复判断条件，减少了循环里的分支，提高了性能，甚至可能解锁向量化优化。
这个模式既适用于微观层面，也适用于宏观架构层面，比如 TigerBeetle 的数据平面就是对批量对象操作，以摊销控制平面决策的成本。
虽然性能是“for 循环往下推”的主要动机，但它也能提升表达力。比如早期很成功的 jQuery 就是针对元素集合的操作，抽象向量空间的语言思维往往比逐个坐标方程更清晰。
最后用一句话总结：把 if 条件往上推，把 for 循环往下推！
📢 2025 全球产品经理技术大会
时间：2025 年 8 月 15–16 日
地点：北京·威斯汀酒店
2025 全球产品经理技术大会将汇聚互联网大厂、AI 创业公司、ToB/ToC 实战一线的产品人，围绕产品设计、用户体验、增长运营、智能落地等核心议题，展开 12 大专题分享，洞察趋势、拆解路径、对话未来。
来源：CSDN一点号