四段没有被调用的代码 —— 不建议直接删,想请你自己看一眼
上线后做了一次全量扫描(1003 个顶层声明),发现只有 4 个从来没有被引用过——
对两万行的项目来说这个数字非常干净,先说这个。
四个都确认过:整个仓库里各自只出现在自己的声明行。
| 名字 |
位置 |
大小 |
我的猜测 |
AOShader |
index.html |
48 行(含完整 GLSL) |
屏幕空间环境光遮蔽着色器。写完了但没接进后处理管线?还是后来被 bloom 那套替代了? |
recoverPlane() |
index.html |
18 行 |
「安全降落到舰上」,还带起落架受损判定。看着是完整可用的,只是没人调用 |
TRACER_COLOR_BY_KIND |
index.html |
1 行 |
按武器类别分曳光颜色。注释写着「4 categories, not 121 — kids track "what kind"」——这个设计理由本身值得留着 |
SURRENDER_FRAC |
index.html |
1 行 |
0.28,投降阈值 |
为什么我没有直接删
AOShader 是 48 行你亲手写的着色器,recoverPlane 是一个完整的功能。
这两个可能是你还没接上去、或者打算以后用的东西——我把它们删掉,等于替你决定它们没价值。
留着 66 行不被调用的代码成本几乎是零;删掉一段你写好的着色器,成本是真的。
所以只是记下来。你自己看:
- 还想要 → 什么都不用做,或者把它接上去(
AOShader 需要在 EffectComposer 里加一个 pass;recoverPlane 需要在降落判定里调用)
- 不要了 → 说一声我删,或者你自己删
两个常量(TRACER_COLOR_BY_KIND / SURRENDER_FRAC)删不删都行,但 TRACER_COLOR_BY_KIND 上面那句注释记录了一个不错的设计判断,就算删代码也建议把注释挪到别处留着。
顺带:整体代码质量的实测数字
既然扫了,把结果一起放这儿——这些数字比我说什么都有说服力:
| 指标 |
结果 |
| 顶层函数 |
581 个,中位数 9 行 |
| 超过 100 行的函数 |
12 个,且都是 build*(几何构建,天然线性)和 update*(每帧状态机) |
| 从未被引用的声明 |
4 个 / 1003 个 |
| 重复三次以上的长行 |
4 组,其中一组还是注释分隔线 |
函数中位数 9 行是很健康的数字。
四段没有被调用的代码 —— 不建议直接删,想请你自己看一眼
上线后做了一次全量扫描(1003 个顶层声明),发现只有 4 个从来没有被引用过——
对两万行的项目来说这个数字非常干净,先说这个。
四个都确认过:整个仓库里各自只出现在自己的声明行。
AOShaderrecoverPlane()TRACER_COLOR_BY_KINDSURRENDER_FRAC0.28,投降阈值为什么我没有直接删
AOShader是 48 行你亲手写的着色器,recoverPlane是一个完整的功能。这两个可能是你还没接上去、或者打算以后用的东西——我把它们删掉,等于替你决定它们没价值。
留着 66 行不被调用的代码成本几乎是零;删掉一段你写好的着色器,成本是真的。
所以只是记下来。你自己看:
AOShader需要在 EffectComposer 里加一个 pass;recoverPlane需要在降落判定里调用)两个常量(
TRACER_COLOR_BY_KIND/SURRENDER_FRAC)删不删都行,但TRACER_COLOR_BY_KIND上面那句注释记录了一个不错的设计判断,就算删代码也建议把注释挪到别处留着。顺带:整体代码质量的实测数字
既然扫了,把结果一起放这儿——这些数字比我说什么都有说服力:
build*(几何构建,天然线性)和update*(每帧状态机)函数中位数 9 行是很健康的数字。