3. 命名规范（二）：参数、宏定义、枚举类型的命名约定
好，咱们接着聊命名。上一章讲了模块、信号、端口的命名，这次我重点说说参数、宏定义和枚举类型。这三个东西在代码里看着不起眼，但用不好真的会出大问题。
我个人习惯是：参数用大写加下划线，宏定义全大写加前缀，枚举类型用大写加后缀。为什么这么分？说白了就是为了一眼能看出这东西是干什么的。
3.1 参数（Parameter）的命名
参数在Verilog里就是parameter和localparam。它们的作用是让模块可配置，比如数据位宽、FIFO深度、计数器最大值等等。
我的命名规则：
- 全部大写字母
- 单词之间用下划线分隔
- 以模块名或功能名开头
- localparam 和 parameter 用同样的风格
推荐写法：
// 模块参数
parameter DATA_WIDTH = 32;
parameter FIFO_DEPTH = 1024;
parameter CNT_MAX_VAL = 100_000;
// 局部参数
localparam STATE_IDLE = 3'b000;
localparam STATE_WRITE = 3'b001;
localparam STATE_READ = 3'b010;你可能会问：为什么不用小写？嗯，这里有个历史原因。早期的一些EDA工具对大小写敏感，而且大写参数在代码里特别显眼。你想想看，在一堆小写信号里突然看到一个大写的DATA_WIDTH，是不是立刻就知道这是个可配置的参数？
避坑指南：我曾经在一个项目里看到有人把参数写成data_width，结果和同名的信号搞混了。仿真跑了三天才发现是参数覆盖了信号值。从那以后，我坚持参数必须大写。
3.2 宏定义（`define）的命名
宏定义是预编译指令，用反引号`开头。它和参数最大的区别是：宏定义是全局的，参数是局部的。所以宏定义的命名要更加小心，避免冲突。
我的命名规则：
- 全部大写字母
- 以项目名或模块名作为前缀
- 用双下划线分隔层级
- 避免使用过于通用的名字
推荐写法：
`define SOC_CLK_FREQ_100M
`define UART_BAUD_RATE_115200
`define DEBUG_ENABLE
`define SIM_FAST_MODE警告：千万不要用`define来定义常量！我见过有人写`define ZERO 0，结果在另一个文件里`define ZERO 1，整个项目就崩了。宏定义是全局替换，没有作用域概念，用不好就是定时炸弹。
我个人建议：能用parameter就别用`define。宏定义只用在以下场景：
- 仿真开关（比如
`ifdef SIM_MODE） - 平台相关的配置
- 全局的时钟频率定义
- 调试信息的开关
3.3 枚举类型（Enum）的命名
SystemVerilog引入了枚举类型，这真是个好东西。但命名如果不规范，枚举反而会让代码更难读。
我的命名规则：
- 枚举类型名以
_e结尾 - 枚举值以大写字母开头，后面小写
- 枚举值加上状态机名作为前缀
- 避免使用数字后缀
推荐写法：
// 状态机枚举
typedef enum logic [2:0] {
FSM_IDLE,
FSM_WRITE,
FSM_READ,
FSM_DONE,
FSM_ERROR
} fsm_state_e;
// 操作模式枚举
typedef enum logic [1:0] {
MODE_NORMAL,
MODE_SLEEP,
MODE_TEST
} operation_mode_e;为什么枚举值要用大写开头？其实没有硬性规定，但我习惯这样写：枚举值在代码里看起来像常量，用大写开头能和其他变量区分开。你想想看，FSM_IDLE和fsm_idle哪个更像一个状态？
小技巧：枚举类型最好加上_e后缀。这样你在代码里看到fsm_state_e，立刻就知道这是个枚举类型。我在项目中用过这个约定，代码审查时大家一眼就能看出类型。
3.4 命名对比表
为了方便你记忆，我整理了一个对比表：
| 类型 | 命名风格 | 示例 | 作用域 |
|---|---|---|---|
| parameter | 全大写 + 下划线 | DATA_WIDTH |
模块内部 |
| localparam | 全大写 + 下划线 | STATE_IDLE |
模块内部 |
| `define | 全大写 + 前缀 | `SOC_CLK_FREQ |
全局 |
| 枚举类型 | 类型名 + _e | fsm_state_e |
包或模块 |
| 枚举值 | 大写开头 + 下划线 | FSM_IDLE |
枚举内部 |
3.5 实战中的坑
我再说几个实际项目中踩过的坑：
- 参数重名：两个模块都用
parameter WIDTH = 8，顶层例化时忘了改，结果一个模块用了另一个模块的宽度。解决方案：参数名加上模块前缀，比如UART_WIDTH。 - 宏定义污染：有人在头文件里写了
`define MAX 100，结果另一个文件里有个变量叫max，被替换成了100。解决方案：宏定义加项目前缀，比如`define PROJ_MAX 100。 - 枚举值冲突：两个不同的枚举类型用了相同的值名，比如
IDLE。解决方案：枚举值加上类型前缀，比如FSM_IDLE和MODE_IDLE。
重要提醒：命名规范不是死规矩，而是为了减少错误。如果你发现某个规范让你的代码更难读，那就改。但改之前，先问问团队里的其他人。
3.6 本章知识体系
下面这张图总结了参数、宏定义、枚举类型的命名要点：
好了，这一章的内容就这些。命名规范这东西，说白了就是约定俗成。你一个人写代码可以随意，但团队协作时必须统一。我见过太多因为命名不规范导致的低级错误，希望你能引以为戒。
可可精品资料库