Ruby Style Guide

原则：

引用

Make it Work, Make it Clean, Make it Fast (if necessary)

1.方法名
全部小写，并且用下划线分开
DO THIS：

def calculate_person_data_usage_history_start_date()  
end

NOT THIS：

Date calculatePersonDataUsageHistoryStartDate() {} 

DO THIS:

def active?
end

def attribute=(name)
end

class T
attr_reader :attribute
attr_accessor :attr
end

NOT THIS：

def is_active
end

def set_attribute
end

def get_attribute
end

此处省略若干字...

2.条件控制
Fine：

x = active? ? 3 : 5

Better：

x = if active? then 3 else 5 end

很长的表达式：

x = if a_really_long_boolean_function
    then a_long_true_value
    else a_long_false_value
    end

x = if a_really_long_boolean_function
      a_long_true_value
    else
      a_long_false_value
    end

Better：

def assign_x
  if a_really_long_boolean_function
    a_long_true_value
  else
    a_long_false_value
  end
end

x = assign_x

if语句后置
Better：

return if x.nil?

Better:

unless logged_in?
  do_something_for_unlogged_in_requests
end

不推荐：
until，while，当然unless里面有else也不推荐
3.习惯用法（推荐）
||= as in, @user ||= User.find(params[:id])

&&= as in, @user.name &&= @user.name.downcase

x.nil? rather than x == nil
x.empty? rather than x.size == 0 — in Rails x.blank? is preferred.

4.链式调用

all_users.select(&:is_active).map(&:name).sort

ruby很容易写出这样长的链式调用，太长了还是分开写好...
当然写个脚本到无所谓。
5.And and or or && and ||（99%的时候||&&是你想要的）

x = y || z
x = (y || z)

x = y or z
(x = y) or z

大多数时候我们想要的是上面的形式..

5.begin rescure end语句
Better：

def sample_method
  do_something
rescue
  raise Exception
end

Ps;在方法中可以省去前面的begin和后面的end，这样显得clean多了。

6.默认参数

def(x, a = 3, b = nil)

等号前后有空格。

7.每行80字符，缩进2字符

a_very_long_method_name(argument1,
    a + b, arg_3)

当然这个如果用hash做参数会写的更漂亮。

8.摆脱括号

个人觉得括号没什么不好，反倒是有时候省略括号总会出现warning，很烦，干脆全用括号了。

评论

17 楼 jetthink 2009-09-04  

下划线的命名规则明显更加符合人的阅读习惯，用了一段时间后，明显感觉能提高效率。
其他多数语言都是pascal和camel规则，看起来太累。
不得不赞一下ruby是code for fun

16 楼 Xorcerer 2009-08-13  

King.Arthur 写道

丑陋的日本人，丑陋的Ruby代码，丑陋的Ruby代码的end尾巴！

前面2/3我就不作评论了，不过最后1/3，你的面杀伤也太大了吧。

15 楼 King.Arthur 2009-07-28  

丑陋的日本人，丑陋的Ruby代码，丑陋的Ruby代码的end尾巴！

14 楼 check 2009-07-28  

关于end，linus torvalds曾经说过：

If you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

    * Linux 1.3.53 CodingStyle documentation. Retrieved on 2006-08-28.

我个人认为90%的情况下end多了是个逻辑思维的问题，而不是排版问题。剩下的确实不好改变的情况，花点时间看看也不是大问题。Python也是，缩进多了不好看，但是合适的代码本来就不应该有那么多缩进

13 楼 jinleileiking 2009-07-27  

icefishc 写道

RednaxelaFX 写道

Hooopo 写道

night_stalker 写道

5 应该有支持的，不过至今都在手动对齐 ……

长度相差太大就算了，相差小的对齐一下（可能是强迫症 ……）

找到了......这个可能算是完美主义者的癖好..

嗯我也是习惯手动对齐的，很自然的就打了一堆空格 OTL

def initialize
  @user      = AppConfig.user
  @password  = AppConfig.password
  @log       = Logger.new AppConfig.log_file || STDOUT
  @log.level = AppConfig.log_level           || Logger::INFO
  yield self if block_given?
end

手动对齐是一种很不人道的事情......
尤其是在修改代码时 如果需要加入一个名字很长的变量 那原先的语句也需要重新对其

  @user      = AppConfig.user
  @password  = AppConfig.password
  @log       = Logger.new AppConfig.log_file || STDOUT
  @balablabala = ...... #  :s 

自动对齐的插件很多 还是找一个吧.

netbeans有这个功能么？radrail也行

12 楼 jinleileiking 2009-07-27  

Hooopo 写道

引用

8.看见这堆 end 会很郁闷，分不清哪个是 end 哪个的：
Ruby代码
        end 
      end 
    end 
  end 
end 

看过有人这样写的：

 
        end#end of ...  
      end#end of ...  
    end#end of each  
  end#end of method  
end#end of class  

00后的IDE都可以支持看到哪个end对应哪个if

话说

if ()
{
} /* end if ....*/

if

end #end of if

估计是C科班出身的。likes me。
而且习惯用sourceinsight

11 楼 jinleileiking 2009-07-27  

calculate_person_data_usage_history_start_date() 
cal_person_data_usage_hist_start_date()

10 楼 RednaxelaFX 2009-07-24  

icefishc 写道

手动对齐是一种很不人道的事情......
尤其是在修改代码时 如果需要加入一个名字很长的变量 那原先的语句也需要重新对其

  @user      = AppConfig.user
  @password  = AppConfig.password
  @log       = Logger.new AppConfig.log_file || STDOUT
  @balablabala = ...... #  :s 

自动对齐的插件很多 还是找一个吧.

嗯，说得没错。确实是在稍微改动之后都要重新对齐。所以之前读一个关于Standard ML的style guide里面就反对等号对齐的做法。
不过我那些对齐也是review的时候才往里加的就是了，最初写代码的时候不会打那么多空格的

9 楼 icefishc 2009-07-24  

RednaxelaFX 写道

Hooopo 写道

night_stalker 写道

5 应该有支持的，不过至今都在手动对齐 ……

长度相差太大就算了，相差小的对齐一下（可能是强迫症 ……）

找到了......这个可能算是完美主义者的癖好..

嗯我也是习惯手动对齐的，很自然的就打了一堆空格 OTL

def initialize
  @user      = AppConfig.user
  @password  = AppConfig.password
  @log       = Logger.new AppConfig.log_file || STDOUT
  @log.level = AppConfig.log_level           || Logger::INFO
  yield self if block_given?
end

手动对齐是一种很不人道的事情......
尤其是在修改代码时 如果需要加入一个名字很长的变量 那原先的语句也需要重新对其

  @user      = AppConfig.user
  @password  = AppConfig.password
  @log       = Logger.new AppConfig.log_file || STDOUT
  @balablabala = ...... #  :s 

自动对齐的插件很多 还是找一个吧.

8 楼 RednaxelaFX 2009-07-24  

Hooopo 写道

night_stalker 写道

5 应该有支持的，不过至今都在手动对齐 ……

长度相差太大就算了，相差小的对齐一下（可能是强迫症 ……）

找到了......这个可能算是完美主义者的癖好..

嗯我也是习惯手动对齐的，很自然的就打了一堆空格 OTL

def initialize
  @user      = AppConfig.user
  @password  = AppConfig.password
  @log       = Logger.new AppConfig.log_file || STDOUT
  @log.level = AppConfig.log_level           || Logger::INFO
  yield self if block_given?
end

7 楼 Hooopo 2009-07-24  

引用

9.空间可以提升阅读的舒适感，适当的时候得多空一几行，多空一几格。

会写RDoc就更完美了。

class CGI

  # :stopdoc:

  # String for carriage return
  CR  = "\015"

  # String for linefeed
  LF  = "\012"

  # Standard internet newline sequence
  EOL = CR + LF

  REVISION = '$Id: cgi.rb 12340 2007-05-22 21:58:09Z shyouhei $' #:nodoc:

  NEEDS_BINMODE = true if /WIN/ni.match(RUBY_PLATFORM) 

  # Path separators in different environments.
  PATH_SEPARATOR = {'UNIX'=>'/', 'WINDOWS'=>'\\', 'MACINTOSH'=>':'}

  # HTTP status codes.

6 楼 Hooopo 2009-07-24  

night_stalker 写道

5 应该有支持的，不过至今都在手动对齐 ……

长度相差太大就算了，相差小的对齐一下（可能是强迫症 ……）

找到了......这个可能算是完美主义者的癖好..

某lib：

      if name.kind_of?(Hash)
        values   = name["VALUES"]
        size     = name["SIZE"].to_s if name["SIZE"]
        multiple = name["MULTIPLE"]
        name     = name["NAME"]
      else
        size = nil
        multiple = nil
      end

PS：貌似也是手动的........后面那两个显然没对齐，哇咔咔

5 楼 Hooopo 2009-07-24  

引用

8.看见这堆 end 会很郁闷，分不清哪个是 end 哪个的：
Ruby代码
        end 
      end 
    end 
  end 
end 

看过有人这样写的：

 
        end#end of ...  
      end#end of ...  
    end#end of each  
  end#end of method  
end#end of class  

4 楼 night_stalker 2009-07-24  

5 应该有支持的，不过至今都在手动对齐 ……

长度相差太大就算了，相差小的对齐一下（可能是强迫症 ……）

3 楼 Hooopo 2009-07-24  

night_stalker 写道

个人推荐风格：

1和4最近一直在用。

      @mail.author.link.icon.should ==\
        "http://t.douban.com/icon/u1057620-20.jpg"

        @table[:link] ||= OpenStruct.new
        @table[:link].
          __send__("#{link.attributes['rel']}=", link.attributes['href'])

5是编辑器支持的吗，不过觉得如果语句长度相差很大这种对齐效果也不是很好。

6我就遇到过在A编辑器上格式良好，在B编辑器格式变乱的情况。原来可以把tab展成空格啊........

2 楼 night_stalker 2009-07-24  

个人推荐风格：

1.子句太长了可以用 \ 换行，换行后缩进 2 格

kill you \
  until you.are dead

2.推荐使用 unless 而不是 if not 或者 if !，这样可以省去很多括号 ……

3. ? : 如果太长，可以这样排版（本人已经很少写 if else end 了 ……）

test ?
  true_clause  :
  false_clause ;

4.我喜欢这样把链调用分行 ……

one.
two.
three.
four rescue nil

5.多行相似语句的关键符号尽量对齐！美观很重要！如下面的 =>

/ie8/        => 'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0)',
/win.*ff/    => 'Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5',
/win.*moz.*/ => 'Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6',

6.设置编辑器把所有 tab 都展成空格，这样在其它编辑器里都有一致的观感。

7.可以这么理解： and or 是连词， && 和 || 是逻辑运算符

sit down and watch tv if true || false

sit down && watch tv # => 语法错误！

8.看见这堆 end 会很郁闷，分不清哪个是 end 哪个的：

        end
      end
    end
  end
end

所以嵌套不要太深，深了分离出子 routine 或者想个法子减少连续的 end 系列。减少嵌套的一个方法：

def m1
  if xxx
    ...
  end
end

改成

def m1
  return if xxx
  ...
end

ps：_why 的 potion 用 . 代替 end，写起来比较搞笑

.....

9.空间可以提升阅读的舒适感，适当的时候得多空一几行，多空一几格。

10.宽 80 字符是上个世纪的限制了 …… 某些时候超出 80 字符是没办法的事情，勉强换行会变丑的 ……

11.命名的经验：
  多次出现的标识符以言简意赅为上（定义处补个详细说明的注释），
  出现得少的或者生存期很长的以详尽清楚为上。

诗体的崇拜者奉上 …… [ 1.9 就不警告括号的事了 ] …… 有空研究下怎么关掉警告。

1 楼 deng131 2009-07-24  

很好的推荐写法。