领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
Ruby编程：清晰明确的代码还是简洁精炼的代码？
作者 Werner Schuster 译者 Jason Lai 发布于 2007年7月30日
Pier Cawley撰文探讨了他在一篇介绍延迟初始化属性的博客文章中发现的潜在问题。出现问题的代码如下：
def content
@content ||= []
end
这段代码的目的是为了支持类的延迟初始化属性。在这个例子当中，除非@content这个实例变量已经初始化完毕，否则在它的访问器方法content方法被调用的时候，它就会被初始化。||=这个操作符意思是“如果左边的变量值为nil，将它的值赋为右边表达式，否则仅返回左边的变量值。”
然而，Piers指出，对于某些值来说，这样做是会出现问题的，因为Ruby处理布尔值和nil的方式比较特殊。我们来看看下面这样一个例子：
a = false
a ||= "Ruby"
这样的代码结果是怎样的呢？由于a已经在第一行被初始化，第二行不应产生任何效果。然而，在代码执行之后，我们会发现a现在的值为"Ruby"，而不是false。
在熟记Ruby中编写nil检查通用方式之后，问题就变得非常显而易见：
if name
puts name.capitalize
end
在Ruby中，nil被解释成布尔值false，因此if子句中的代码只有在name的值不等于nil的时候才能运行。
尽管在通常意义上这不会成为一个问题，但是在延迟初始化属性的代码中，如果付给属性的合法值是nil或者false的时候，这就会成为一个问题。在这种情况下，对属性进行访问之后，属性值就会被重设成缺省值。
当然，这是一个边界情况，但是这样的问题会导致人们花很长时间进行调试，来试图找出到底为什么某些方法有些时候会被重设而另外一些则不会。
Piers为这段代码给出了一个条理更为清晰的代码：
def content
unless instance_variable_defined? :@content
@content = []
end
return @content
end
这样，代码只会在变量还没有被定义的时候才会初始化变量。
通过这个小例子，我们可以把错误归咎于Ruby及其部分语言特性——但哪一类程序员会把错误归咎于工具而不是他们自身，这已经是众所周知的事实了。尽管Ruby代码的简洁性非常有用，但还是有一些情况下使用更加明确表达意图的表达式会更安全一些。在这个例子中，||=并非正确的解决方案，相反初始化代码应当检查变量是否已经被定义。
亲爱的读者，您在以前是否也被这样的问题敲中脑门呢？Ruby是否存在哪些你希望避免的语言特性，以预防上述难于发现的问题呢？
查看英文原文：Explicit vs. concise code in Ruby
这个陷阱不具通用性
发表人
刘 松
发表于
ruby就是太灵活了
发表人
张 立
发表于
并非陷阱
发表人
fei li
发表于
Re: 并非陷阱
发表人
good gpy
发表于
我不认为这是个问题
发表人
zane dennis
发表于
-
尽管ruby变量可以被赋给任意类型的值,但变量代表的固定意义,使得值的类型多数情况只能一种或少数几种(比如Symbol,String几种). 这个讨论指出了我们可能遇到的陷阱，但没有太大通用性。
-
ruby就是太灵活了
-
||=这个操作符意思是“如果左边的变量值为nil，将它的值赋为右边表达式，否则仅返回左边的变量值。”
解释似乎有误。
我们知道||或运算具有“短路”的性质，也就是只要计算为true就不再计算余下表达式，而直接返回真了。所以||=这个操作符 应该是首先计算 ||=左边的值，为true的话，就直接返回左边的值，为false的话就继续计算，计算 ||=右边的表达式。所以等号右边的表达式是否计算取决于 ||左边的布尔测试。其实a ||= b 应该是 a || a=b 的简写。 -
你出于某个目的使用一个变量，当你接下来再次使用这个变量肯定是因为相同的目的，可能的混乱根本不会发生。这与ruby需要静态类型的担心是一样的道理。
-
是的.同意.
该文作者是不是s了点
5 条回复
关注此讨论 回复