short变量名不应带_t或short_前缀，应直接用业务语义名如age、port；short即short int，无需写全；struct中需注意内存对齐；仅在接口契约、内存敏感或abi兼容时才用short。
short 变量名该不该带 _t 或 short_ 前缀
不用。C++ 标准库没提供 short_t，你自己加 short_t 或 short_val 反而干扰语义——short 本身已是明确类型，命名只需表达业务含义。
常见错误现象：short_t count 让人误以为是 POSIX 的 int16_t；short_count 把类型信息塞进名字，违背“变量名描述‘是什么’，而非‘是什么类型’”的基本原则。
- 推荐：用
age、port、status_code这类能体现用途的名，编译器和 IDE 自然知道它是short - 如果真需强调位宽（如协议字段），优先用固定宽度类型：
int16_t，再配清晰名：header_length - 团队已有约定（如统一加
s_表示 signed short）？那就遵守，但别对外推广——它不解决实际问题，只增加认知负担
定义 short int 时要不要写全 int
完全没必要。short 就是 short int 的等价缩写，C++ 标准明确规定二者无区别，写 short int 纯属冗余。
使用场景：只有在教学或代码审查中需要显式强调“这是整型”时才可能临时出现，生产代码里几乎见不到。
立即学习“C++免费学习笔记（深入）”；
- 写
short x;即可，干净且符合习惯 -
short int y;不报错，但会让同事多看半秒——这半秒积累起来就是维护成本 - 注意：不能写成
int short z;，顺序错会编译失败：error: 'int' is not a type
short 在 struct 里容易引发的内存对齐陷阱
不是值本身出问题，而是它在结构体里的位置会影响整体大小和访问性能。尤其当 short 前后夹着 char 和 int 时，编译器可能悄悄补空字节。
示例：
struct A {
char c;
short s; // 编译器很可能在这儿补 1 字节对齐到 2 字节边界
int i;
};
结果 sizeof(A) 很可能是 12 而非 7 —— 因为 int 通常要 4 字节对齐。
- 若在意内存紧凑（比如网络包、嵌入式），把
short和其它小类型集中放前面或后面 - 用
[[gnu::packed]]或#pragma pack(1)强制压缩？可以，但会牺牲未对齐访问性能，x86 上可能只是慢一点，ARM 上可能直接触发异常 - 更稳妥的做法：用
static_assert(sizeof(A) == N, "unexpected padding")锁定布局，比靠经验猜可靠得多
什么时候真该用 short 而不是 int
极少。现代 CPU 处理 int（通常是 32 位）反而比 short 更快，因为寄存器和 ALU 都按自然字长设计。除非你明确受限于外部约束。
真实使用场景只有三个：接口契约要求、内存极度敏感、或历史 ABI 兼容。
- 文件格式或网络协议规定字段必须是 16 位？用
int16_t，比short更可靠（short只保证 ≥16 位，某些 DSP 平台可能是 32 位） - 数组超大（千万级），且数值确定在 -32768~32767 内？这时省一半内存才有意义
- 调用 C API（如 Windows 的
WORD、Linux 的__u16）？必须严格匹配类型，否则 ABI 可能错乱
其他情况，老老实实用 int 或 int32_t。省那两个字节换来的，往往是调试半天才发现的符号扩展 bug 或跨平台差异。
