RuboCop 内部审计：强制要求 RESTRICT_ON_SEND 的最佳实践

在 Ruby 静态代码分析工具 RuboCop 的开发过程中，我们发现了一些可以自动检测的隐式规则。本文将重点介绍如何通过自定义 InternalAffairs 检查器来确保 Cop 类的性能优化。

为什么需要 RESTRICT_ON_SEND

RESTRICT_ON_SEND 是 RuboCop 中的一个重要性能优化机制。当 Cop 类定义了 on_send 或 after_send 方法时，通过指定 RESTRICT_ON_SEND 数组，可以限制 Cop 只对特定的方法调用进行检查，而不是对所有方法调用都进行处理。

这种限制能显著提升 RuboCop 的运行效率，特别是在大型代码库中。想象一下，如果一个 Cop 需要检查所有方法调用，而实际上它只关心少数几个特定方法，那么大部分处理都是不必要的。

实现原理

我们开发了一个 InternalAffairs/RequireRestrictOnSend 检查器，它会自动检测以下情况：

1. 检查类是否继承自 RuboCop::Cop::Base
2. 检查类中是否定义了 on_send 或 after_send 方法
3. 验证是否同时定义了 RESTRICT_ON_SEND 常量

这个检查器使用了 RuboCop 强大的 AST 模式匹配能力，能够识别各种形式的定义方式，包括：

• 直接的方法定义
• 通过 alias 创建的方法别名
• 通过 alias_method 创建的方法别名

高级特性

检查器还包含了一些智能判断逻辑：

• 只对真正的 Cop 类进行检查（继承自 Base 或 Cop）
• 忽略普通 Ruby 类中的同名方法
• 支持各种形式的常量定义
• 能够处理复杂的类继承结构

实际应用示例

以下是一个符合要求的 Cop 类示例：

class MyCustomCop < RuboCop::Cop::Base
  RESTRICT_ON_SEND = %i[bad_method].freeze
  
  def on_send(node)
    # 检查逻辑...
  end
end

性能优化建议

除了 RESTRICT_ON_SEND 外，我们还发现 Cop 类中方法实现的另一个优化点：避免在方法开始处进行变量赋值。为此我们开发了 InternalAffairs/AssignmentFirst 检查器，它会提示开发者将赋值操作移到方法逻辑之后，这样可以：

1. 提高代码可读性
2. 减少不必要的变量初始化
3. 遵循"先检查后处理"的最佳实践

总结

通过引入这些 InternalAffairs 检查器，我们可以：

• 强制实施 RuboCop 开发的最佳实践
• 提高自定义 Cop 的性能
• 保持代码风格的一致性
• 减少潜在的性能问题

这些检查器已经在包含75个自定义 Cop 和约100万行 Ruby 代码的实际项目中验证了其有效性，是 RuboCop 开发中值得推广的实践方案。