SwiftFormat 中属性声明分类的优化与思考

在 Swift 开发中，代码的组织和格式化对于项目的可维护性至关重要。SwiftFormat 作为一款强大的代码格式化工具，其属性声明分类功能在实际使用中出现了一个值得探讨的问题：带有 didSet/willSet 观察器的存储属性被错误归类为计算属性。

问题背景

SwiftFormat 默认会将带有代码体的实例属性归类到"Computed Properties"（计算属性）部分。然而，这种分类方式存在一个明显的逻辑问题：存储属性虽然可以带有 didSet 或 willSet 观察器，但它们本质上仍然是存储属性，而非计算属性。

例如，以下代码：

var foo: Bar = .baz {
  didSet {
    // 执行某些操作
  }
}

会被错误地归类到计算属性部分，而实际上它应该属于常规属性部分。

技术分析

这个问题源于 SwiftFormat 内部对属性分类的实现逻辑。当前版本中，所有"带有代码体的实例属性"（instancePropertyWithBody）都被统一标记为"Computed Properties"，这种粗粒度的分类忽略了存储属性观察器与计算属性之间的本质区别。

在 Swift 语言中：

• 计算属性：不存储值，通过 getter 和可选的 setter 来间接获取和设置其他属性或值
• 存储属性：实际存储值，可以附加 willSet 和 didSet 观察器来监控属性值的变化

解决方案探讨

SwiftFormat 维护团队提出了两种可能的解决方案：

1. 修改标记注释：将当前的"Computed Properties"标记改为更准确的"Properties with body"，这样虽然不够精确，但至少不会产生误导。

2. 重构分类系统：创建新的"computedInstanceProperty"声明类型，并将"instancePropertyWithBody"从默认的组织模式中移除。这样带有观察器的存储属性会回退到常规"instanceProperty"分类中。

第二种方案更为理想，因为它能够更精确地区分不同类型的属性，符合 Swift 语言的设计哲学。这种方案需要：

• 定义新的属性分类标准
• 调整默认的组织模式配置
• 确保向后兼容性

临时解决方案

在官方修复发布前，开发者可以通过自定义标记标题来临时解决这个问题。SwiftFormat 支持用户为特定属性类型指定自定义的 MARK 注释，虽然这个功能目前文档不够完善，但在实践中是可行的。

总结与展望

代码组织工具的设计需要在简洁性和准确性之间找到平衡。SwiftFormat 团队对这个问题的处理展示了他们对代码质量的高度重视。随着 Swift 语言的演进，类似的工具也需要不断调整以适应新的语言特性和开发者的实际需求。

这个问题已在 SwiftFormat 0.55.5 版本中得到修复，体现了开源社区快速响应和持续改进的优势。对于开发者而言，理解工具背后的设计思路有助于更有效地使用它们，并在遇到类似问题时能够提出建设性的改进建议。