|
|
最近在整理团队的易语言项目，踩了不少坑，逐渐意识到：所谓“代码规范”不是束缚，而是让协作这件事少点摩擦、多点确定性的最低成本工具。尤其在易语言这种语法相对宽松、写法多样的环境里，没有约束就等于放任复杂度滋生。下面聊聊我们团队落地的一些做法和体会，供参考，也欢迎拍
砖。
先说命名。易语言变量默认全中文并非罪过，但混搭拼音、缩写和英文会让新人抓狂。我们的约定是：业务域优先中文，全局与跨模块的基础库统一英文小写加下划线；布尔用“是否/has/is”前缀，过程（函数）用动词开头，常量全大写。更重要的是一致性：要么整仓库都用“客户_编号”，要么整仓库都用“customer_id”，不要今天“khbh”、明天“custNo”。
注释不是流水账。易语言的“说明”格外容易被滥用，结果是每行都有注释但一句废话。我们要求三类注释必须写：模块/过程头注（做什么、输入/输出、异常/返回
码）、关键分支的意图注释（不是“如果x大于0则进入”，而是“处理余额补差场景”），以及临时性妥协的TODO/FIXME，必须附带责任人和到期时间。其余地方尽量用可读代码替代注释，避免“注释和实现打架”。
格式化要让机器干脏活。我们把缩进、对齐、空行规则固化到编辑器模板里
，把“保存即格式化”作为强制钩子。函数体内控制缩进层级不超过三层，超过就拆分过程；长行超过 100 字符自动换行；参数列表对齐到同一列，方便一眼看全。代码风格不靠自觉，靠工具和失败的提交。我们用预提交脚本做了两件事：检测未格式化文件直接拒绝提交；扫描违规命名并给出建议替换。
分层与
分层与模块边界要在仓库结构里“看得见”。我们把项目按“接口层-应用层-领域层-基础设施层”做了最小化切分：界面事件只做数据收集与展示，不写业务判断；应用层编排流程，领域层承载规则和模型，基础设施负责文件/数据库/外部接口。每一层暴露的过程都写清楚契约，禁止跨层调用“抄近道”。这样做的好处是新人定位改动范围更快，回归测试也更聚焦 |
|
发表于 
微信公众号
官方抖音号