一位开发者提交的代码让同事Fredrika看愣了：一个本该处理双向数据转换的类，Convert方法什么都没做，反向转换也仅对空字符串特殊关照。

这一切要从WPF的IValueConverter接口说起。在WPF的数据绑定世界里，控件和后台数值之间的类型转换靠的是实现这个接口的类，标准模板要求你既实现Convert（模型→控件），也实现ConvertBack（控件→模型）。微软官方文档里给出的示例就很随性：颜色到画刷的转换，转回时直接返回了null——因为根本不需要反向转。

Fredrika的同事偏偏要弄个最基础的“字符串转双精度浮点数”转换器。盯着需求看：文本框清空了，对应数值字段最好变成null而不是0。于是这位码农大手一挥，写下了这样的逻辑：Convert方法接到value后，把它当成double?原样返回——严格来说是啥也没转换；ConvertBack方法从文本框拿字符串，如果是空串就返回null，否则把字符串丢回去。用代码说话就是

public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture) { double? parsed = value as double?; return parsed; }
public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture) { string parsed = value as string; if (parsed == string.Empty) return null; return parsed; }

这就形成了一个特别滑稽的职责分配：往控件显示方向根本不动弹，从控件取值方向只盯着空文本。写代码的人或许觉得自己完美解决了“空值”需求，但读到这段代码的网友很难憋住问一句——那普通字符串转double的部分谁干？答案是，扔给了.NET框架内置的默认转换机制。于是整个转换器就成了一层极薄的包装，薄到近乎透明，只在空串这一种情形下刷了刷存在感。

原帖作者在文章里直接摊手：“我不喜欢这个转换器API，也不喜欢这个实现，更不喜欢把空文本框当作null的用法——我确信这种处理在当前场景是对的，但天晓得会在什么地方出问题。”一连串的“我不喜欢”仿佛道尽了所有接手过这种代码的开发者的心声：看似什么都做了，又好像什么都没做；看似解决了痛点，又埋下了只有未来调试时才会引爆的雷。

或许每个团队都有那么一段“能跑就行”的历史遗产，只是有些遗产的设计思路，就像这个转换器一样——在某个方向上彻底摆烂，在另一个方向上只对空气挥了挥拳头。