PHP-CS-Fixer 中 native_type_declaration_casing 规则对常量大小写的影响分析

在 PHP 代码规范修复工具 PHP-CS-Fixer 的最新版本中，开发者发现了一个关于类型声明大小写规则与常量大小写规则交互的有趣问题。这个问题涉及到代码风格自动修复时不同规则之间的优先级和影响关系。

问题现象

当开发者从 PHP-CS-Fixer 3.68.1 升级到 3.68.3 版本后，发现代码中的 TRUE/FALSE/NULL 等常量被自动转换为小写形式，即使配置中明确设置了 constant_case 规则要求保持大写。具体表现为：

// 修复前（期望保持大写）
if ($zip->open($archive_path) === TRUE) {
  
// 修复后（被改为小写）
if ($zip->open($archive_path) === true) {

技术背景

PHP-CS-Fixer 中有两个相关规则：

1. constant_case 规则：控制 PHP 常量的命名风格（大写、小写）
2. native_type_declaration_casing 规则：控制原生类型声明的大小写（如 int, string, bool 等）

在正常情况下，这两个规则应该各司其职，互不干扰。constant_case 应该负责 TRUE/FALSE/NULL 等常量的风格，而 native_type_declaration_casing 应该只处理类型声明。

问题根源

经过开发者测试和项目维护者确认，这个问题源于 3.68.2 版本中的一个修复（#8386）。该修复原本是为了解决其他问题，但意外影响了常量大小写的处理逻辑。

关键点在于：

• 新版本中 native_type_declaration_casing 规则错误地将 TRUE/FALSE/NULL 识别为类型声明而非常量
• 这导致即使配置了 constant_case 规则要求大写，这些"伪类型声明"仍被强制转为小写
• 本质上是一个规则边界划分和优先级处理的问题

解决方案

项目维护者已经确认这是一个确实存在的 bug，并承诺会很快发布修复版本。对于遇到此问题的开发者，临时解决方案包括：

1. 暂时回退到 3.68.1 版本
2. 在配置中明确禁用 native_type_declaration_casing 规则
3. 等待官方发布包含修复的新版本

最佳实践建议

这个案例提醒我们几个重要的开发实践：

1. 在升级代码规范工具时，应该在小范围测试后再全面应用
2. 复杂的规则组合可能会产生意想不到的交互效果
3. 保持关注项目的 issue 追踪，及时了解已知问题
4. 考虑在 CI/CD 流程中加入代码风格检查的验证步骤

对于 PHP 代码规范，建议团队明确约定：

• 类型声明统一使用小写（如 bool, int）
• 常量根据项目规范选择大小写（通常建议大写）
• 保持整个项目中的风格一致性

这个问题也展示了自动化代码修复工具的复杂性，即使是成熟的工具如 PHP-CS-Fixer 也需要不断优化规则间的交互逻辑。