2014-12-30 29 views
6

我在我的代码,如设置符号:Ruby的符号设置

"name_of_symbol".to_sym 

然而,我的首席工程师在代码审查作为一种不好的做法把它捡起来,并问我设置一样的符号:

:"name_of_symbol" 

当我问他为什么?他说这是不好的做法,但是当我问他刚才说的是什么原因时,这并不是一个令人满意的答案。所以怎么回事?有没有什么区别?

+5

它似乎是在你的工作场所的惯例,而不是一个“坏习惯”的问题。约定就是这样,不需要争论(为什么我们称“树”为“树”而不是“搀杂”?因为我们同意使用“树”)。有些人可能会说“可读性” - 但是没有做过实际的科学研究来证明:sym语法更容易阅读,这只是一个说法。另一方面,如果这个人拒绝给出一个解释,那么我们不能帮助你:(我的意思是:用':sym'定义一个符号,但是为了明确地转换为符号,使用'.to_sym'。 –

+4

它不是不好的做法不好的做法是,当你是项目团队的领导者时,不可能解释一些事情 –

+0

这也不是一个好的做法,请注意,如果你的符号不包含空白和其他所以':foo_bar'确实没有引号,你只需要引用':“foo bar”' –

回答

3

其他的答案正确地争辩说:"foo bar"优于"foo bar".to_sym,因为它是更清晰,更好的表达你的意图,更具有可读性,速度更快等,但还有一个原因:"foo bar".to_sym依靠String#to_sym方法,并有可能(虽然很遥远),这种方法可能会被重新定义。这是为什么:"foo bar"原则上更好的做法的一个非美容理由。

+3

的确,虽然重新定义to_sym肯定会导致全球骚乱。 –

+0

它肯定会。这基本上是一个纯粹的理论论证。 –

6

冒号表示符号。我不会称之为不合常规的做法,这可能会使代码难以理解。

我知道:"Some weird stuff"是合法的,但不喜欢它,我个人宁愿使用:Some_weird_stuff并将引号全部放在一起 - 当您不需要时使用引号只是增加噪音 - 我很抗噪。噪音是不好的做法,这会让理解需要更长的时间。

有时候,当你匹配进来作为字符串的东西,但为了保持一致性,你想要的符号,那么你没有太多的选择,但我不希望要问这个问题,FWIW。

当你有语法干净的符号,你可以使用

{ thing: "value" } 

语法,这是一种快乐和非常清晰,整洁。

有趣的是,虽然:

irb 
> class String ; def to_sym ; puts "bob" ; end ; end 
    => nil 
> "fred".to_sym 
    bob 
    => nil 
> :"fred" 
    => :fred 

所以鲍里斯点是一个有效的。

+0

我可能应该在我的问题中注意到,它在动态设置符号的时候会像array.each {| s | “#{s}”to_sym –

+4

所以你有一个字符串,你在做:“#{s}” - 亲自我会用to_sym,插入一个字符串,然后在后台调用to_sym ...有点毫无意义,我想:) – Ghoti

+3

换句话说,不要做':“#{s}”'或'“# {s}“。to_sym','s.to_sym' – Ajedi32

4

其中一个是Symbol字面值,另一个是您调用方法的字面值String

就个人而言,我觉得很奇怪写String当你的意思写了Symbol,只有然后立即转换StringSymbol。为什么不首先写一个Symbol?这使你的意图更清晰。

+1

这不是奇怪的,例如,如果某种方法返回一个字符串,然后'method_which_returns_a_string.to_sym'是要走的方式 –

+0

@RustamA。加沙诺夫:但这不是这个问题的关键。问题是直接使用符号字面值,而不是字符串文字,然后将其转换为符号。显然,完全不同的问题可能会有完全不同的答案。 –

2

这似乎是一个偏好问题,但我可以看到如何编写符号作为符号比编写要更改为符号的字符串更清晰。

而且,当你使用snake_case引号是不必要的。

  1. "name_of_symbol".to_sym
  2. :"name_of_symbol"
  3. :name_of_symbol

这是一个风格问题,但在我看来,3是三种最可读的,简洁的版本。如果“最佳实践”意味着容易阅读并因此保持,我会说3胜。