Ruby Quiz

通常不会比Java程序更难懂，我觉得

是。代码难不难懂，取决于写程序的人，不在于语言本身。只有在编写者过分追求技巧的时候，才会产生那种写10分钟，看明白需要1个小时的代码

跟语言还是有关系的,这就是语言的表达能力了

刚刚我看到小伙子在写一个函数,其中的参数表示超时,但是有一个缺省值,他写到:

if (options["timeout"]);
  @timeout = options["timeout"]
else
  @timeout = DEFAULT_TIMEOUT
end

但是如果写成

  @timeout = options["timeout"] || DEFAULT_TIMEOUT

是不是更可读一点呢?

 @timeout = options["timeout"] || DEFAULT_TIMEOUT

这个是最简单的，但未必是最可读的。
毕竟，需要了解 null等于false这个特性。
从可读性来讲，不如：

int timeout = options.contains("timeout");? options["timeout"]:DEFAULT_TIMEOUT

当然，罗嗦了一些。
一般在条件语句中的各个条件中加括号的意思也是一样的，可以避免考察读者判断逻辑运算符的优先级的能力。

charon兄你狡辩了，你这段代码明显没有potian代码更可读呀

@timeout = options["timeout"] || DEFAULT_TIMEOUT

按我这个行业的习惯,这样写真的很成问题.一来||的左右求值序到底是那种并不确定，依赖于语言和编译器解释器的实现.第二,如果  options["timeout"] 如果是一个函数运算,这个函数是不是执行依赖于||另外一端的求值以及编译器是不是进行截断求值，非常的可怕的写法.

在c是个问题, 在ruby不是问题, 呵呵.

写习惯就好了（意味着读者也习惯了）。C写法： flag |= option 不一样也习惯了吗:D

要是更多值在后面，差距就明显了。比如取a.b.c，如果链中有一个是空则返回空：

x = a && a.b && a.b.c

用if或那个三元运算符不给人郁闷死。

对于这种情况还是groovy的安全导航爽
x = a->b->c （语法总变来变去的，不知现在这样还行不）

c 有问题吗,10多年用下来好像还是第1次听说

不一定啊。

@timeout = options["timeout"] || DEFAULT_TIMEOUT

这句代码，其实缺少了几个必要的信息，而且，如果用在动态语言上的话，有可能带来其它的意外
1. 没有直接传递关于@timeout的类型信息
当然，写代码的人是知道的。而读代码的人，只能根据名称做直觉判断。虽然这里比较明确，但多数情况下，是不能够根据变量名准确判断出类型的，当然，严格的匈牙利命名法除外。
按照对称性的做法，如果options["timeout"]非null,则其类型应当为DEFAULT_TIMEOUT.但是这里没有给出DEFAULT_TIMEOUT的类型，所以需要跳转或前向索引.
这就相当于代码编写者为了把这个类型信息传递给代码阅读者，而迫使阅读者搜索这段语句之外的位置
2. 这里用到了逻辑操作中null等同于false的特性。这是一个双棱剑。当为null时，直接变成了
@timeout = null || DEFAULT_TIMEOUT，然后变成 false || DEFAULT_TIMEOUT,实际上已经破坏了前面的那种对称性。
不过这个不是最重要的。
问题是对于动态语言，实际上并不能判断出options到底是一个映射还是普通的类实例(此时timeout是一个属性)，那么也不知道这是一个属性还是一个索引得到的值。如果options是一个映射，那不会有问题(其实也有问题，但只是类型一致性的事情)。否则，这里就必须对missing-property有一个隐含一致的处理方式，即必然返回null/false. 这在有些场合下是有问题的。
对于代码阅读者而言，必须确认这一点(毕竟去阅读代码的情形，或者是去理解，或者是去发现问题)。因此，需要对options对象作一个了解。
另外一个问题，接着前面前面T1大大的，这个options的属性求值会不会有副作用(一般是在missing-property的时候会作一些其它处理). 不过这个比较少见。

而

int timeout = options.contains("timeout");? options["timeout"]:DEFAULT_TIMEOUT

则没有上述两点的问题(当然了，上面这一段实际上也不是合法的java代码，不过改一下很快的)，实际上是把隐含的东西明确化了。
罗嗦，但提高了可读性。