CSharpier 格式化工具中 new() 操作符与显式构造函数的格式不一致问题分析

在 CSharpier 代码格式化工具中，开发人员发现了一个关于对象初始化表达式格式化的不一致性问题。这个问题涉及到 C# 9.0 引入的目标类型 new 表达式（即 new() 语法）与传统的显式构造函数调用在格式化行为上的差异。

问题现象

当使用目标类型 new 表达式时，CSharpier 会将其格式化为多行形式：

ProblemDetails problemDetails =
    new()
    {
        Status = StatusCodes.Status500InternalServerError,
        Title = "An unexpected error occurred. Please try again later.",
        Detail = environment.IsDevelopment() ? exception.Message : null,
        Instance = context.Request.Path,
    };

而使用传统显式构造函数时，格式化结果则保持为单行起始：

ProblemDetails problemDetails = new ProblemDetails
{
    Status = StatusCodes.Status500InternalServerError,
    Title = "An unexpected error occurred. Please try again later.",
    Detail = environment.IsDevelopment() ? exception.Message : null,
    Instance = context.Request.Path,
};

技术背景

C# 9.0 引入的目标类型 new 表达式（Target-typed new expressions）是一种语法糖，它允许编译器根据赋值目标的类型推断 new 表达式的类型。这种语法简化了代码，特别是在类型名称较长或重复时能显著提高可读性。

从格式化角度看，这两种语法在功能上是等价的，因此理想情况下应该具有相同的格式化行为，以保持代码风格的一致性。

问题影响

这种不一致性可能导致以下问题：

1. 代码风格混乱：在同一个项目中混合使用两种语法时，会出现不同的格式化结果
2. 可读性降低：new() 的多行格式化可能不必要地增加了垂直空间占用
3. 迁移障碍：从显式构造函数迁移到目标类型 new 表达式时，会意外改变代码格式

解决方案分析

理想的解决方案是统一两种语法的格式化行为。考虑到显式构造函数的格式化方式更为紧凑且被广泛接受，建议将 new() 的格式化调整为与之相同的风格：

ProblemDetails problemDetails = new()
{
    Status = StatusCodes.Status500InternalServerError,
    Title = "An unexpected error occurred. Please try again later.",
    Detail = environment.IsDevelopment() ? exception.Message : null,
    Instance = context.Request.Path,
};

这种调整有以下优点：

1. 保持一致性：与现有显式构造函数的格式化风格统一
2. 节省空间：减少不必要的行数
3. 符合直觉：开发者预期功能等效的语法应该有相似的视觉呈现

实现考量

在实现这种格式化规则时，需要考虑以下边界情况：

1. 超长行处理：当声明部分过长时，适当的换行仍然是必要的
2. 嵌套初始化：复杂对象初始化表达式的格式化需要保持清晰
3. 注释位置：确保注释能正确跟随格式化后的代码

总结

代码格式化工具的核心价值之一就是保持一致的代码风格。对于 CSharpier 这样的工具来说，识别并修正这种语法等价但格式化不一致的情况非常重要。通过统一 new() 和显式构造函数的格式化行为，可以提升代码的整体一致性和可读性，同时减少开发者在使用不同语法时的认知负担。