路由器固件开发中，代码命名规则怎么定才不翻车？

刷过OpenWrt、Padavan或者自己编译过LEDE固件的朋友应该都踩过坑：改了几个函数名，结果编译报错；加了个新配置项，后台页面死活不显示；甚至重启后WiFi模块直接失联——最后发现，问题出在变量名写成了wifi_en，而框架里默认认的是wifi_enabled。

命名不是写作文，是给机器和人同时看的

路由调优不是纯前端开发，底层涉及大量C、Shell脚本和Lua逻辑。比如OpenWrt的LuCI界面，配置保存靠/etc/config/wireless，读取靠uci get wireless.@wifi-iface[0].disabled。如果你在自定义脚本里把开关变量起名叫is_off，而UCI配置段里用的是disabled，那再漂亮的UI也白搭。

几条实战中磨出来的硬规矩

1. 配置项名必须小写+下划线，且语义明确
别写WifiEnable或wifi_on，统一用wifi_disabled（注意：OpenWrt习惯用disabled=1表示关闭）。这样uci set wireless.@wifi-iface[0].disabled='0'才能被正确识别。

2. Shell变量避免大写和短名
写个重启WiFi的脚本时，别用W=1或STA_MODE这种缩写。实际调试中你根本记不住STA_MODE到底是“站模式”还是“静态地址”。改成wifi_station_mode_enabled，一眼就懂，grep也方便。

3. Lua里别碰驼峰，老老实实下划线
LuCI模板里经常要传值：

local wifi_status = uci:get_first("wireless", "wifi-iface", "disabled")

如果后端Lua返回一个叫isWifiOn的字段，前端JS还得二次转换。不如从源头就用is_wifi_enabled，前后端直接对齐。

反面例子：一串名字，全在猜

某次帮朋友修自定义QoS脚本，看到这些变量：qos_flag、en_q、qos_switch、qos_on……四个变量干同一件事，但没注释、没文档。最后逐行echo才发现，只有qos_switch真正控制iptables规则开关，其它全是历史残留。

4. C模块里结构体字段名要带前缀
比如写个驱动扩展，定义AP扫描参数结构体：

struct ap_scan_cfg {
    int scan_interval_ms;
    int max_scan_time_ms;
    char ssid_filter[33];
};

别写成interval、timeout这种泛泛的名字——同一文件里可能还有beacon_interval、rekey_timeout，混在一起谁分得清？

命名这事，真不是炫技。你在SSH里敲vi /usr/share/rpcd/acl.d/xxx.json改权限配置时，看到"uci.wireless.wifi_disabled"能秒懂，比写十行注释都管用。