如何简化ParseHeight方法？提升代码质量的技术咨询

嘿，你的直觉太对了——这个动辄几十行的switch语句完全没必要，咱们可以利用字符的ASCII值连续性直接计算对应数值，轻松摆脱冗余的case判断！

先理清楚原方法的映射逻辑：

• 数字字符 '0'-'9' → 对应0-9
• 小写字母 'a'-'w' → 对应10-32
• 其他字符直接抛出FormatException

最简洁高效的方案：字符差值计算 #

这是我最推荐的方式，没有多余的转换或集合操作，直接通过字符的数值差算出结果：

public static short ParseHeight(char input)
{
    if (input is >= '0' and <= '9')
    {
        // '0'的ASCII值是48，用input减去'0'就能直接得到对应的数字
        return (short)(input - '0');
    }
    else if (input is >= 'a' and <= 'w')
    {
        // 'a'对应10，所以用input减'a'再加10，就是对应的数值
        return (short)(input - 'a' + 10);
    }
    else
    {
        // 原提示里写的是(0-k)，但实际支持到w，这里修正一下更准确
        throw new FormatException("The input was not in a correct format: input must be between (0-w)");
    }
}

结合你提到的.ToString()解析方案（可选） #

如果你更习惯用ToString()转数字的方式，也可以把数字分支单独处理，和字母逻辑结合：

public static short ParseHeight(char input)
{
    if (char.IsDigit(input))
    {
        // 把字符转成字符串再解析成int，最后转short
        return (short)int.Parse(input.ToString());
    }
    else if (input is >= 'a' and <= 'w')
    {
        return (short)(input - 'a' + 10);
    }
    else
    {
        throw new FormatException("The input was not in a correct format: input must be between (0-w)");
    }
}

不过这种方式多了一步字符串转换，性能比直接字符减法略低一点，除非你有特殊需求，不然还是首选第一种方案。

适合复杂映射的字典方案 #

如果未来可能需要调整映射规则（比如非连续的对应关系），用字典预先存映射表也是个不错的选择，可读性拉满：

// 把字典定义成静态字段，避免每次调用方法都重新创建
private static readonly Dictionary<char, short> _heightMapping = new()
{
    {'0',0}, {'1',1}, {'2',2}, {'3',3}, {'4',4}, {'5',5}, {'6',6}, {'7',7}, {'8',8}, {'9',9},
    {'a',10}, {'b',11}, {'c',12}, {'d',13}, {'e',14}, {'f',15}, {'g',16}, {'h',17}, {'i',18}, {'j',19},
    {'k',20}, {'l',21}, {'m',22}, {'n',23}, {'o',24}, {'p',25}, {'q',26}, {'r',27}, {'s',28}, {'t',29},
    {'u',30}, {'v',31}, {'w',32}
};

public static short ParseHeight(char input)
{
    if (_heightMapping.TryGetValue(input, out var result))
    {
        return result;
    }
    throw new FormatException("The input was not in a correct format: input must be between (0-w)");
}

这种方式的好处是映射关系一目了然，修改起来特别方便，但初始化字典会有一点点额外开销，对于当前这个简单场景来说，前两种方法更轻量。

为啥这些方案比switch强？ #

• 简洁度拉满：代码行数直接砍半，逻辑一眼就能看明白
• 维护更轻松：要是以后要扩展支持到'x'，改个条件或者加个字典项就行，不用加一堆case
• 性能更优：前两种方法的条件判断比几十条case的分支跳转效率更高（case越多差距越明显）

对了，原方法的异常提示里写的是"(0-k)"，但实际代码支持到'w'，记得修正一下提示信息哦~

内容的提问来源于stack exchange，提问作者user5405648