欢迎来到51自学网!

51自学网

当前位置: 主页 > 脚本专题 >

浅析Ruby的源代码布局及其编程风格

时间:2018-03-17 11:13来源:网络整理 作者:51自学网 点击:
使用 UTF-8 作为源文件编码。 每个缩进级别使用两个 spaces (又名软 tabs). 不要硬 tabs # bad - four spaces def some_methoddo_something end# good def some_methoddo_something end 使用 Unix-风格 换行符。(*BSD/

使用 UTF-8 作为源文件编码。

    每个缩进级别使用两个 spaces (又名软 tabs). 不要硬 tabs

# bad - four spaces def some_method do_something end # good def some_method do_something end

    使用 Unix-风格 换行符。(*BSD/Solaris/Linux/OSX 用户被为默认涵盖,Windows 用户必须特别小心.)

        如果你正在使用 Git 你可能会想要添加下面的配置设置来保护你的项目(避免)Windows 蔓延过来的换行符:

 

$ git config --global core.autocrlf true

    不用使用 ; 来分割语句和表达式。以此推论 - 一行使用一个表达式

  

# bad puts 'foobar'; # superfluous semicolon puts 'foo'; puts 'bar' # two expression on the same line # good puts 'foobar' puts 'foo' puts 'bar' puts 'foo', 'bar' # this applies to puts in particular

    对于没有内容的类定义,尽可能使用单行类定义形式.

   

# bad class FooError < StandardError end # okish class FooError < StandardError; end # good FooError = Class.new(StandardError)

    避免单行方法。即便还是会受到一些人的欢迎,这里还是会有一些古怪的语法用起来很容易犯错.
    无论如何 - 应该一行不超过一个单行方法.

    

# bad def too_much; something; something_else; end # okish - notice that the first ; is required def no_braces_method; body end # okish - notice that the second ; is optional def no_braces_method; body; end # okish - valid syntax, but no ; make it kind of hard to read def some_method() body end # good def some_method body end

    空方法是这个规则的例外。

# good def no_op; end

    操作符旁的空格,在逗号,冒号和分号后;在 { 旁和在 } 之前,大多数空格可能对 Ruby 解释(代码)无关,但是它的恰当使用是让代码变得易读的关键。

sum = 1 + 2 a, b = 1, 2 1 > 2 ? true : false; puts 'Hi' [1, 2, 3].each { |e| puts e }

    唯一的例外是当使用指数操作时:

# bad e = M * c ** 2 # good e = M * c**2

    { 和 } 值得额外的澄清,自从它们被用于 块 和 hash 字面量,以及以表达式的形式嵌入字符串。
    对于 hash 字面量两种风格是可以接受的。

# good - space after { and before } { one: 1, two: 2 } # good - no space after { and before } {one: 1, two: 2}

    第一种稍微更具可读性(并且争议的是一般在 Ruby 社区里面更受欢迎)。
    第二种可以增加了 块 和 hash 可视化的差异。
    无论你选哪一种都行 - 但是最好保持一致。

    目前对于嵌入表达式,也有两个选择:

# good - no spaces "string#{expr}" # ok - arguably more readable "string#{ expr }"

    第一种风格极为流行并且通常建议你与之靠拢。第二种,在另一方面,(有争议)更具可读性。
    如同 hash - 选取一个风格并且保持一致。

    没有空格 (, [之后或者 ], )之前。

 

some(arg).other [1, 2, 3].length ! 之后没有空格 . # bad ! something # good !something

    when和case 缩进深度一致。我知道很多人会不同意这点,但是它是"The Ruby Programming Language" 和 "Programming Ruby"中公认的风格。

    

# bad case when song.name == 'Misty' puts 'Not again!' when song.duration > 120 puts 'Too long!' when Time.now.hour > 21 puts "It's too late" else song.play end # good case when song.name == 'Misty' puts 'Not again!' when song.duration > 120 puts 'Too long!' when Time.now.hour > 21 puts "It's too late" else song.play end case when song.name == 'Misty' puts 'Not again!' when song.duraton > 120 puts 'Too long!' when Time.now > 21 puts "It's too late" else song.play end

    当赋值一个条件表达式的结果给一个变量时,保持分支的缩排在同一层。

 

# bad - pretty convoluted kind = case year when 1850..1889 then 'Blues' when 1890..1909 then 'Ragtime' when 1910..1929 then 'New Orleans Jazz' when 1930..1939 then 'Swing' when 1940..1950 then 'Bebop' else 'Jazz' end result = if some_cond calc_something else calc_something_else end # good - it's apparent what's going on kind = case year when 1850..1889 then 'Blues' when 1890..1909 then 'Ragtime' when 1910..1929 then 'New Orleans Jazz' when 1930..1939 then 'Swing' when 1940..1950 then 'Bebop' else 'Jazz' end result = if some_cond calc_something else calc_something_else end # good (and a bit more width efficient) kind = case year when 1850..1889 then 'Blues' when 1890..1909 then 'Ragtime' when 1910..1929 then 'New Orleans Jazz' when 1930..1939 then 'Swing' when 1940..1950 then 'Bebop' else 'Jazz' end result = if some_cond calc_something else calc_something_else end

    在方法定义之间使用空行并且一个方法根据逻辑段来隔开。

   

def some_method data = initialize(options) data.manipulate! data.result end def some_methods result end

    避免在一个方法调用的最后一个参数有逗号,特别是当参数不在另外一行。

   

(责任编辑:admin)

织梦二维码生成器
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
栏目列表
推荐内容