C#的未来：简化参数空值验证
极客时间编辑部
讲述：丁婵大小：8.00M时长：05:50
提案 #2145 似乎是 C# 8 可空引用类型特性的逻辑扩展。其基本思想是，开发人员不需要再显式地向接受非空参数的方法添加参数空值检查。然而，人们对于这个特性的争议很大。
最近，InfoQ 编辑乔纳森·艾伦（Jonathan Allen）发文试图说明这些提案选项以及它们的利弊，以便读者能够得出自己的看法。以下为艾伦的观点。
先来简要说明为什么可空引用类型特性在 C# 8 中仍然很重要。
目前，可空引用类型特性只是提供信息。它会警告开发人员在处理空值时出现的常见错误，但仅在编译时发出警告。当应用程序运行时，所有这些编译时检查都不存在。
此外，在使用反射或 Dynamic 时，编译检查根本不起作用。
下面是提案中的建议以及它们的利弊。
特定语法：感叹号操作符
原来的建议是使用感叹号操作符，告诉编译器应添加参数空值检查。
这个选项的理由是破坏性小，只需要对 C# 编译器做一个小修改，并且新语法完全向后兼容。
反对这一选项的理由是：
它是一种适用面很窄的新语法；
在阅读代码时很容易忽略它；
很容易忘；
声明参数不可为空是多余的。
另一个问题是是否有意义，意味着“请检查这个值是否为空”或“不需要检查，它不是空的”，这取决于上下文。为了解决后一个问题，该提案的一个变体是使用双感叹号操作符（string value!!）。
新属性
即增加编译器可以识别的新属性，而不是新语法。
就 C# 而言，影响编译代码的属性并不是什么新事物，所以这可以与现有的模式保持一致。如果我们以前有声明性参数验证，它也会是这样的。
反对这一选项的理由是：
与正在考虑的其他选项相比，它非常啰嗦；
声明参数不可为空是多余的。
编译标识
下一个要考虑的选项是全局编译器标识。当该标识启用时，将检查所有非空参数。这个选项的好处是你不需要考虑它，一旦启用，检查就会自动添加，这样就不会忘记，也不需要学习特殊的语法。
对此，第一个反对意见是，这可能存在性能方面的考虑。该选项的支持者认为，性能成本微不足道，该特性可以选择性地仅应用于公共方法，但允许对任何方法调用执行空值检查。
第二个反对意见是，开发人员可能希望抛出不同的异常。支持者认为，除了 ArgumentNullException 之外，不应该抛出任何东西。此外，编译器指令可以在需要特殊处理时仅针对一个文件或方法禁用该特性。
最后一个观点认为编译器标识实际上并不会改变代码的行为方式，它只是一个编译时特性。但“checked”编译器标识是个例外，它会改变整数溢出的行为。这在 C# 语言设计人员看来是一个错误，因为如果不知道编译器级如何设置标识，你就无法判断给定代码段的操作方式。
反对者并没有反驳这一点，但是，保持这项更改是使可空引用类型特性接近完成的必要步骤。对此，一些人坚持认为，NRT 从来就不是一个完备的解决方案，为了向后兼容，它不应该影响运行时行为。
外部 AOP 和 IL 织入
反对 IL 织入的理由是它需要第三方工具，不能很好地与 IDE 中运行的静态分析工具协同，会破坏 Edit-and-Continue，降低构建速度。
内部 AOP 或宏系统
有一些关于某种内部 AOP 或宏指令的讨论。这将允许开发人员扩展语言本身，而不是等待 C# 的增强。
该选项并没有得到太多支持。内部 AOP 或宏系统会造成整个工具链的重大变化。此外，它可能会让开发人员创建自己的 C# 方言，造成语言割裂。
什么也不做
最后一个选项是什么也不做。最有力的论据是，这仅仅是一个“生活质量”特性，并没有为开发者提供任何新的东西。虽然减少样板文件这点值得赞赏，但它们的负面影响超过了其所带来的好处。
而且，在任何给定的函数中，只需要少量代码来执行空检查。
反驳的观点是，这是 C# 中最常见的样板代码示例之一，在示例和生产代码中经常缺失。对此，这一选项的支持者给出的回复是，静态分析工具将检测出大部分（尽管不是全部）空值检查的情况。启用 NRT 后，静态分析检查可以变得更加准确。
以上就是今天的内容，欢迎在评论区留下你的观点。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论