《编程的智慧(初稿)》读后感

Update:

王垠更新了文章,加入了Optional跟Union比较的内容,所以我也来更新一下。垠神认为Optional并没有什么卵用,Java8的Optional我不是很了解,不过看他写的样子,应该是个用了泛型的容器类,而且从他举的例子来看,确实没什么卵用,不管是报NoSuchElementException还是NullPointerException都是运行时错误,的确换汤不换药。至于他说Swift的Optional跟Java是一样的问题么,我觉得还是有待商榷,之前我也说了强制解包语法!是为了兼容OC类库,毕竟Swift这个语言主要还是为了做iOS开发,总是有些历史包袱。如果不滥用的话,Swift的Optional还是个不错的特性。至于垠神说的在类型外面包一个数据结构会导致程序变得复杂,比如Java的Optional如果要安全使用的话,就得先判空(x.isPresent())再取对象(x.get()),这确实很蛋疼,还不如直接用原先的类型,使用前先判空就是了。想比之下Swift的if letguard let就好很多,判空跟取值一步到位,若为空就取不到值,若不为空就直接取值并赋值,干净利落。

垠神口中的union类型比Optional好很多,我觉得有道理。嗯,不过我觉得Swift的Optional也已经不错了,毕竟设计一个工业语言,要考虑的东西非常复杂,要兼顾各种历史遗留问题、迎合当前市场等等,有些坑也在所难免。作为语言使用者,多了解相关知识,在实际应用的时候多注意点就好了。

原文:

《编程的智慧(初稿)》王垠最近写的一篇文章,看完有一点想法,由于垠神没有开通评论,所以我把读后感写到了知乎的一篇回答中,全文如下:

仔细看了一遍,说得很具体也挺实在,也没有像之前那样掺杂很多自吹自擂的成分。

反复修改代码如何让程序模块化那部分我很认同,平常自己基本也是这样做的。如何写出可读的代码主要是说要恰当地命名使代码可以自解释,复杂的逻辑可以提取成一个函数然后进行调用,这样又可以用函数名进行自解释,从而减少注释。只有在少有的一些针对项目特殊情况而写但不符合直觉的地方使用注释。这些显然也是非常正确的,要不然我也不会经常为取个合适的函数名纠结半天了。

编码规范方面么,他也基本说服了我。我偶尔也会用点所谓的“奇技淫巧”从而减少几行代码,可能会给读代码的人造成额外的负担,以后尽量少用。

至于无懈可击地处理corner case那部分么,我个人还是喜欢使用卫语句提前return的,一大堆if-else嵌套让我觉得不愉快。之前还写过一篇博客——人生充满选择,编程也是,说了一些减少if-else嵌套的方法。当然由于我觉得王垠虽然说话叼了一点,编程方面还是挺厉害的,所以我决定尝试下他的建议,然后看看具体效果。至少目前,我还是坚持自己的观点的。

最后是对待和处理Null指针那部分,一路看下来我都觉得很有道理,跟我的想法也契合,直到看到这段:

一个正确的类型系统,会报告因为find()返回了{A, NULL}(而不是A),而NULL里面根本没有一个叫value的成员,所以x.value这种写法不合法。这种可靠的union类型系统,已经存在于Typed Racket和Yin语言里面,然而工业界的语言要发展到这一步,恐怕还要等很多年。

看看,又不客观了吧,这说的不就是Swift中的Optional类型么?我觉得Swift中的Optional类型已经基本解决了他在文章中提到的关于Null指针的问题。当然由于要兼容Cocoa Touch中的OC类库(也可能有方便使用方面的考虑),Swift还提供了隐式解包类型(就是声明变量时类型后面加个!而不是?,比如Int!),如果滥用这个特性的话,经常会出现这个错误——unexpectedly found nil while unwrapping an optional value,这也是个运行时错误,跟空指针错误也没太大区别,所以要注意不要滥用!

C#中也有Optional类型,但是Swift中的Optional类型比C#中的范围更广一些(C#中的Optional只是针对值类型的,引用类型是可以为null的;Swift中所有类型都不能为nil,只有Optional类型才能为nil,就像王垠说的那样,nil就是nil,它不能成为别的类型),所以C#的Optional对于王垠说的问题是没什么用的。两种Optional的比较我之前一个答案写过,全文如下:

C#中早就有Optional了,只不过C#中Optional是用在像intdecimal之类的基本类型中,感觉主要是为了让语义更顺一些,譬如有一个Person类,它有一个属性Age,是int类型,但有的人你可能不知道他的Age,如果没有Optional的话就只能把Age赋值为0或者负数,用来表示不知道具体年龄。但这显然不符合直觉,有了Optional之后,就可以把Age声明为int?类型,如果不知道具体年龄Age就可以设为空。

Swift更极端一些,任何类型都不能为nil,只有该类型对应的Optional才能是nil。Optional其实是一个枚举类型,它有两个枚举值,一个为空,一个为解包后的实际值。在Swift中Optional主要还是为了安全考虑。合理使用Optional的话,基本就不会出现空指针错误导致App崩溃的情况。声明不允许为nil的变量的时候,就不要用Optional,这样如果不慎在开发过程中这个变量为nil了,编译器在编译期就会给出错误提醒,而且在使用这个值的时候也不用再去判断它会不会为nil了。至于可能为nil的变量,那不得不用Optional,使用时尽量使用if let或者guard let进行解包。至于因为没有在构造函数中对其进行初始化,而你又确定会在别处(在使用它之前)对它赋值的属性,可以在声明的时候使用隐式解包语法,也就是把类型后面的"?"换成"!",这样在使用的时候就不需要进行显式解包了。

总的来说Optional是个不错的设计,使用得当可以提高应用的稳定性。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

通过java程序模拟实现地铁票价2+2=12(r3笔记第94天)

地铁票价在这周六开始就要上涨了,这几天做地铁明显感觉人比平常多了很多。大家也都在默默的等待这一刻的到来,尽管很不情愿,但是终究会来。 到时候肯定吐槽的人一抓一大...

2666
来自专栏take time, save time

你所能用到的数据结构(八)

十一、不能被应用的理论不是好研究 前面介绍了堆栈的一些小小的理论模型,那么这样一个东西有什么作用呢?实际中不可能有那么一辆停在站台前方堵死的火车的,即使有,也...

2704
来自专栏技术墨客

Java函数式开发——优雅的Optional空指针处理

    在Java江湖流传着这样一个传说:直到真正了解了空指针异常,才能算一名合格的Java开发人员。在我们逼格闪闪的java码字符生涯中,每天都会遇到各种nu...

1192
来自专栏java学习

Java每日一题_关于类继承常见的易错面试题

子类的构造方法总是先调用父类的构造方法,如果子类的构造方法没有明显地指明使用父类的哪个构造方法,子类就调用父类不带参数的构造方法。 而父类没有无参的构造函数,...

1152
来自专栏鹅厂优文

Python 工匠:善用变量来改善代码质量

我一直觉得编程某种意义上是一门『手艺』,因为优雅而高效的代码,就如同完美的手工艺品一样让人赏心悦目。

99510
来自专栏程序员互动联盟

【答疑解惑】i++,++i,i+=的区别

说起这个i++, ++i 入门练习都会搞这个,一如既往,百试不爽。 表达式 a = i++; 它等价于 a = i ; i = i + 1; 表达式 a = ...

3185
来自专栏北京马哥教育

Python 工匠:善用变量来改善代码质量

1598
来自专栏Golang语言社区

转-Golang语言Interface漫谈

一件作品的诞生,通常是一个设计师独立完成的。因为这样,一件建筑也好,画作或者音乐舞蹈也好,才能真实反映出其个性。而正是这种不同于其他同类的独特一面,正是这种发自...

3265
来自专栏青玉伏案

设计模式(十):从电影院中认识"迭代器模式"(Iterator Pattern)

上篇博客我们从醋溜土豆丝与清炒苦瓜中认识了“模板方法模式”,那么在今天这篇博客中我们要从电影院中来认识"迭代器模式"(Iterator Pattern)。“迭代...

19810
来自专栏iKcamp

翻译连载 |《你不知道的JS》姊妹篇 |《JavaScript 轻量级函数式编程》- 第 7 章: 闭包 vs 对象

原文地址:Functional-Light-JS 原文作者:Kyle Simpson-《You-Dont-Know-JS》作者 第 7 章: 闭包 vs 对象 ...

2347

扫码关注云+社区

领取腾讯云代金券