Foundry Lint 规则详解：immutable 变量必须使用 `SCREAMING_SNAKE_CASE`（screaming-snake-case-immutable）-北京尧图网络

Foundry Lint 规则详解immutable 变量必须使用SCREAMING_SNAKE_CASEscreaming-snake-case-immutable【免费下载链接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.项目地址: https://gitcode.com/GitHub_Trending/fo/foundry本篇文章围绕 Foundry 自带的 Solidity Lint 规则screaming-snake-case-immutable展开深入讲解它检查什么、为什么推荐 immutable 变量使用全大写蛇形命名以及这条规则在源码中的判定逻辑与测试验证方式。读完本文你将掌握该规则的完整语义含单字符豁免与下划线保留等边界行为、如何用forge lint复现并修复告警以及如何在真实项目中权衡重命名与兼容性。规则概览screaming-snake-case-immutable是 Foundry Lint 体系位于 crates/lint 目录中的一条命名规范类规则元信息定义在规则文档中严重级别SeverityInfo规则 IDscreaming-snake-case-immutable作用对象声明为immutable的状态变量这条规则与同族的screaming-snake-case-const针对constant变量见对应文档共享同一套底层检查逻辑只是对immutable与constant分别发出不同的告警 ID。它检查什么该规则报告所有标识符偏离SCREAMING_SNAKE_CASE命名约定的immutable状态变量并带有两条明确的豁免边界单字符名称不检查单个字符的变量名如address immutable X;不会触发告警。这是因为单字符命名在循环索引、临时变量等场景中极为常见且无法形成有意义的全大写形态。首尾下划线保留命名转换时会保留变量名最前面和最后面的下划线。也就是说_OWNER、OWNER_这样的写法仍被视为合规内部下划线则由转换逻辑统一处理。示例如下来自规则文档// 不合规小驼峰 / 大驼峰 address immutable owner; address immutable Owner;应改为// 合规SCREAMING_SNAKE_CASE address immutable OWNER;为什么推荐这种命名规则文档给出了两条核心理由视觉上与constant对齐Foundry 推荐 immutable 变量使用SCREAMING_SNAKE_CASE使它们在代码中与constant常量在视觉上保持一致。由于 immutable 与 constant 都在部署后不可再修改只是时机不同——constant 在编译期内联immutable 在构造时赋值用同一套命名风格能让读者一眼识别出这些值不会变。在调用点与可变状态区分开状态变量mutable遵循 Solidity 风格指南的mixedCase小驼峰而 immutable/constant 使用全大写蛇形这样在函数体内引用这些变量时无需追溯声明即可从命名上区分可变与不可变语义显著降低阅读成本。另外规则文档也给出了一条重要的例外原则如果项目已经有一套区分 immutable 与 constant 的既定命名惯例或者变量存在已对外公开的 getter 名称而重命名会造成破坏性影响如影响 ABI 中 getter 的 selector、破坏其他合约的引用则应保留原有命名。这是一条Info级别的风格建议而非强制约束。源码实现判定逻辑与自动修复规则的实际实现位于 crates/lint/src/sol/info/screaming_snake_case.rs它通过 solar 的 AST 遍历对每个变量定义执行检查implast EarlyLintPassast for ScreamingSnakeCase { fn check_variable_definition( mut self, ctx: LintContext, var: ast VariableDefinitionast, ) { if let (Some(name), Some(mutability)) (var.name, var.mutability) let Some(expected) check_screaming_snake_case(name.as_str()) { let lint match mutability { VarMut::Constant SCREAMING_SNAKE_CASE_CONSTANT, VarMut::Immutable SCREAMING_SNAKE_CASE_IMMUTABLE, }; emit_rename(ctx, lint, name.span, expected); } } }从源码结构可以看出几个关键设计单一 Pass 双规则ScreamingSnakeCase这一个 Lint Pass 同时注册了两条告警SCREAMING_SNAKE_CASE_CONSTANT与SCREAMING_SNAKE_CASE_IMMUTABLE通过VarMut枚举区分Constant与Immutable并分发到不同的规则 ID注册关系见 crates/lint/src/sol/info/mod.rs。自动修复emit_rename会生成一条MachineApplicable级别的建议修复见 crates/lint/src/sol/naming.rs提示语为consider using: 期望名称也就是说forge lint --fix这类机器可应用修复可以直接把不合规的命名改写为正确形式。转换算法底层使用heck库的AsShoutySnakeCase把标识符转换为全大写蛇形见 naming.rs例如screamingSnakeCase→SCREAMING_SNAKE_CASE、ScreamingSnakeCase0→SCREAMING_SNAKE_CASE0。单字符豁免与下划线保留的实现边界行为在 naming.rs 中体现得十分明确/// Single-character names are exempt from every convention. fn suggest(s: str, expected: String) - OptionString { (s.len() 1 s ! expected).then_some(expected) } fn preserve_underscores(s: str, body: String) - String { let prefix if s.starts_with(_) { _ } else { }; let suffix if s.ends_with(_) { _ } else { }; format!({prefix}{body}{suffix}) }suggest中s.len() 1的判断正是单字符名称不检查的实现长度不大于 1 时直接返回None不产生告警。preserve_underscores负责首尾下划线保留转换前先记录首/尾下划线转换完成后重新拼回去。例如_SCREAMING_SNAKE_CASE_1会被判定为合规首下划线保留、主体已合规而SCREAMING_snake_case_0会被建议改为SCREAMING_SNAKE_CASE_0见下文测试用例。测试用例验证规则在 crates/lint/testdata/ScreamingSnakeCase.sol 中配有完整的测试夹具fixture通过行内注释//~NOTE: immutable name is notSCREAMING_SNAKE_CASE 标记期望告警的位置//compile-flags: --severity info ... uint256 immutable _SCREAMING_SNAKE_CASE_1 0; // 合规首下划线保留 uint256 immutable SCREAMING_SNAKE_CASE_1 0; // 合规 uint256 immutable SCREAMINGSNAKECASE0 0; // 合规全大写连续字母允许 uint256 immutable SCREAMINGSNAKECASE_ 0; // 合规尾下划线保留 uint256 immutable screamingSnakeCase0 0; // ~NOTE: 不合规 uint256 immutable screaming_snake_case0 0; // ~NOTE: 不合规 uint256 immutable ScreamingSnakeCase0 0; // ~NOTE: 不合规 uint256 immutable SCREAMING_snake_case_0 0; // ~NOTE: 不合规对应的期望输出在 ScreamingSnakeCase.stderr 中展示了实际的告警渲染效果与自动修复建议例如note[screaming-snake-case-immutable]: immutable name is not SCREAMING_SNAKE_CASE LL │ uint256 immutable SCREAMING_snake_case_0 0; │ ━━━━━━━━━━━━━━━━━━━━━━ help: consider using: SCREAMING_SNAKE_CASE_0这些测试用例同时验证了文档中提到的所有边界条件小驼峰、全小写下划线、大驼峰、混合大小写均会被报告而全大写无论是否含数字、下划线以及带首尾下划线的写法均被放行。注意测试夹具通过//compile-flags: --severity info显式将严重级别阈值降到Info因为该规则默认级别为Info需要相应配置才能在输出中展示。在项目中启用与修复由于该规则属于Info级别在默认严重级别配置下可能不会在forge lint输出中展示需要将级别阈值调低例如测试中使用的--severity info。典型的使用方式# 以 Info 级别运行全部 lint输出包含本规则 forge lint --severity info # 只运行某一条规则通过规则 ID 过滤 forge lint --severity info --path path/to/Contract.sol也可以参考 crates/config/src/lint.rs 中定义的 lint 配置结构在foundry.toml中调整规则级别或按路径忽略告警。修复时既可以直接手动改写命名也可以依赖机器可应用的自动修复建议一键替换为SCREAMING_SNAKE_CASE形式。小结screaming-snake-case-immutable是 Foundry 代码质量体系中一条轻量但实用的命名规范规则它要求immutable状态变量采用与constant一致的SCREAMING_SNAKE_CASE命名从而在调用点快速区分不可变与可变状态。规则实现上通过共享的命名检查助手crates/lint/src/sol/naming.rs同时服务 constant 与 immutable 两类变量并内置了单字符豁免与首尾下划线保留两个贴心边界测试夹具ScreamingSnakeCase.sol则完整覆盖了这些语义。如果你的项目已有成熟且稳定的 immutable 命名惯例或公开 getter规则文档也明确建议保留既有命名避免重命名带来的兼容性破坏——这正是这条Info级别规则建议而非强制的定位所在。【免费下载链接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.项目地址: https://gitcode.com/GitHub_Trending/fo/foundry创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Foundry Lint 规则详解：immutable 变量必须使用 `SCREAMING_SNAKE_CASE`（screaming-snake-case-immutable）

相关推荐

51单片机音乐盒设计：Proteus仿真与定时器驱动蜂鸣器详解

Mac Mouse Fix 快速上手：侧键与平滑滚动，让任意鼠标拥有触控板手感

SpringBoot+Vue3作业管理系统技术解析与实践

更多资讯

WPS在Linux下打不开中文文件？KDE桌面启动器修复指南

MATLAB实现改进型SEIR3疫情传播模型与参数敏感性分析

Linux动态库undefined symbol定位与修复实战

OpenCV轮廓匹配实战：用Hu矩实现5分钟形状识别

基于ZYNQ的FPGA DDS信号发生器设计与实现

内网HTTPS部署：用openssl自签名证书解决Chrome“不安全”提示

今日更新

基于MATLAB的CRI显色指数计算：从SPD光谱到Ra的完整流程

JSP+Servlet+MySQL博客系统源码部署与优化全攻略

蜂窝调度算法 MATLAB 实现：比例公平、轮询与最大 C/I 对比

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？