if user.vegetarian? && !user.smoker? && (user.age < 25) && (user.n_girlfriends == 0) && (user.first_name =~ /(A|Z)[0-1]+/)
end
在方法中移动内容,使内容不仅更短,而且可读性更好:
if user.healthy? && user.has_a_weird_name?
# Do something
end
# in User
def healthy?
vegetarian? && !smoker? && (age < 25) && (n_girlfriends == 0)
end
def user.has_a_weird_name?
user.first_name =~ /(A|Z)[0-1]+/
end
execute <<-SQL
UPDATE people
SET smoker = 0
OK, this is a very bad example.
SQL
查询
对于简单的情况,我倾向于这样做:
# Totally random example, it's just to give you an idea
def cars_older_than_n_days(days)
Car.select("cars.*, DATEDIFF(NOW(), release_date) AS age")
.joins(:brand)
.where(brand: {country: "German"})
.having("age > ?", days)
end
# starting point (line is too long)
def send_mail(source)
Mailer.deliver(to: 'bob@example.com', from: 'us@example.com', subject: 'Important message', body: source.text)
end
# bad (double indent)
def send_mail(source)
Mailer.deliver(
to: 'bob@example.com',
from: 'us@example.com',
subject: 'Important message',
body: source.text)
end
# good
def send_mail(source)
Mailer.deliver(to: 'bob@example.com',
from: 'us@example.com',
subject: 'Important message',
body: source.text)
end
# good (normal indent)
def send_mail(source)
Mailer.deliver(
to: 'bob@example.com',
from: 'us@example.com',
subject: 'Important message',
body: source.text
)
end
# bad - need to consult first line to understand second line
one.two.three.
four
# good - it's immediately clear what's going on the second line
one.two.three
.four
它通常被证明是一个“解决方案”,用于过于复杂的代码,正如@Aldo已经提到的:
# bad
some_condition ? (nested_condition ? nested_something : nested_something_else) : something_else
# good
if some_condition
nested_condition ? nested_something : nested_something_else
else
something_else
end
4条答案
按热度按时间yh2wf1be1#
简单的回答是这取决于。
基础知识
首先,你可以使用“新的”Ruby哈希语法来保存一些字符:
对比
哈希/数组
有时候你需要初始化一个数组或哈希,特别是对于哈希,这样写很好:
在同一行上的相同哈希将是(不那么好):
各种方法调用
有些方法需要很多参数,或者这些参数有很长的名字:
在这种情况下,我可能会这样写:
它仍然不是很漂亮,但我想它没有那么丑。
再说一遍,不是地球上最漂亮的代码,但它有某种结构。
此外,有时您可以使用变量来拆分行。这只是一个例子,但基本上你命名的东西块(有时在此之后,你意识到你实际上可以移动块在一个方法)
区块
闭包(Closes):
可以这样写:
如果你有合适的块,尝试使用do-end而不是花括号:
条件
不要在复杂的事情中使用三元if运算符:
如果你有像这样复杂的if语句:
在方法中移动内容,使内容不仅更短,而且可读性更好:
长字符串
Heredoc是你的朋友...我总是需要谷歌,以获得正确的语法,但一旦你得到它的权利是使某些事情更好地阅读:
查询
对于简单的情况,我倾向于这样做:
有时候查询更糟糕。如果我使用squeel并且查询很大,我倾向于使用括号,如下所示:
我会说,如果可能的话,尽量避免复杂的查询,并将它们拆分到较小的范围内或其他:
这可能是最好的办法。
现实
不幸的是,人们倾向于写很长的行,这是不好的:
git diff
之类的东西时,有很长的线路是痛苦的我的编辑器里有一把尺子,这样我就能知道什么时候我会越过第80个字符。但很少越过几个字符的线,这实际上比分裂它更好。
总结
有几种方法可以保持80年代以下的线路,通常取决于情况。长行的问题不仅仅是糟糕的风格,长行通常是太复杂的症状。
fcg9iug32#
沿着如下的东西:
或者,如果你想突出选项哈希(一个合理的事情):
把所有这些都放在一行上的想法让我觉得是一个糟糕的想法,这意味着你必须滚动任意的数量才能看到被委派的内容。真恶心
我可能也会把东西排成一行,也许按字母顺序排列。
如果文件没有太多/任何其他实质性内容,我可能会将每个方法符号放在自己的行中,只是为了使编辑更容易。在一个更大的文件中,我不想占用空间。
我从没想过这种事。
这些天来,我可能会根据“相似性”对委托方法进行分组,大致如下:
当值也是一个符号时,我的陪审团坚持1.9的哈希语法;我觉得很好笑。我也不确定要缩进到哪里--在IDE重新格式化时可能会丢失它,但如果我使用新语法,我会喜欢上面的样子。
6rvt4ljy3#
虽然这个问题已经有了两个很好的答案,但我还是想让未来的读者参考Ruby Style Guide来解决这些问题。
目前,源代码布局部分有大量关于如何在各种情况下断行的信息:
它通常被证明是一个“解决方案”,用于过于复杂的代码,正如@Aldo已经提到的:
d7v8vwbk4#
从我的经验来看,似乎惯例实际上并不是要打破线路。我见过的大多数项目,包括rails本身的代码库,似乎都不存在很长的不间断行的问题。
所以我想说,如果你想遵循惯例,就不要打断队伍。如果你决心打破界限,那么就没有广泛遵循的惯例。您可以使用您喜欢的任何编码风格。