Ruby 这两种风格的 ruby 代码大 PK
- 你自己写哪种。
- 当你需要维护他人代码时，代码是哪种。
- 当我说上面两个代码可能有 bug 时，你觉得哪个代码的 bug 好确认。
其实我有严重的倾向性：我期望第 1 种。
class Integer
def fact
(1..self).reduce(:*) || 1
end
end
抄的 stackoverflow 的，他又是抄的http://rosettacode.org/wiki/Factorial#Ruby的
好像大家都觉得 思考第 2 种风格的代码是否有 bug 的时间比第 1 种少
个人感觉就算熟悉 inject 的人，在考虑实现 bug 时，思考复杂度第 2 种也更高。
刚从别的语言转过来时用第一种，对 ruby 的各种方法了解了以后用第二种。ruby 的方法特别是 Array、String 这两个类的方法太重要了，最好把这两个类的所有方法都滚瓜烂熟
第二种。并且我倾向于使用 reduce 而不是 inject，虽然它们互为别名。
第一种是过程式编程的风格。手动定义中间变量，手动迭代，手动相加。
第二种是函数式编程的风格。将 fact 的运算思考成一个以 1 到 n 的数组的 reduce 相乘。如果用 haskell 来写的话，第一种根本写不出来。
第二种一眼就能看出干什么， 第一种花费的时间更长一点。
有简洁的函数式用，为啥还要用 C 语言样的过程？
除非有一种可能，就是代码暂时是用的 Ruby 写的， 不久的未来是打算迁移到 C/C++ 上的。
关键问题是，第一种写法并没有增加可读性啊。反而因为多了冗余信息，我感觉可读性还下降了。
当然，从来没接触过 Ruby 的人，可能更容易看懂第一种写法，但问题是这样的人，还敢让他维护 Ruby 代码？那得是多心宽啊。
歪楼的来了~
"程序的优雅性不是可以或缺的奢侈品，而是决定成功还是失败的一个要素。优雅并不是一个美学的问题，也不是一个时尚品味的问题，优雅能够被翻译成可行的技术。牛津字典对 elegant 的解释是：pleasingly ingenious and simple。如果你的程序真的优雅，那么它就会容易管理。第一是因为它比其它的方案都要短，第二是因为它的组件都可以被换成另外的方案而不会影响其它的部分。很奇怪的是，最优雅的程序往往也是最高效的。
为什么这么少的人追求优雅？这就是现实。如果说优雅也有缺点的话，那就是你需要艰巨的工作才能得到它，需要良好的教育才能欣赏它。"
为什么有人说别的语言转 Ruby 会写第一种，我的第一反应是：:
def fact(n)
if n == 0
1
else
n * fact(n - 1)
end
end
或者用？:三元运算符写成单行版。
这个问题本质上是抽象模式 和 协作便捷性 间的权衡。
第二种是函数式编程，抽象模式上更接近问题域，更具有表达性。因此第二种在抽象模式上完胜。 如果你的协作对象是没有函数式思想的程序员（无论他是不是新手），用第二种编程方式对于协作者而言并不友好。
如果是我，我会用第二种编程方式，但会加上注释给协作者解释第二种的意思。
第一种，一开始就 return，表面看似节能，其实对于代码的维护带来不少的麻烦， 第二种，虽然自己也经常用，虽然简洁，但也不是正确的写法。
一个良好的习惯就是，
1，开始对所有要用的值进行初始化。 2，返回值 放到最后，尽量不要中间 return 或开头。
不同的人有不同的看法，但我是从一个软件的设计和维护来看待这个问题