先说几个核心判断：Ruby 的代码风格问题，看似是“个人喜好”之争，实则是团队协作效率的命门。一个项目，如果每个人写出来的代码长得都不一样，那维护成本会直接飙升。下面这份风格指南，基本上就是业界公认的“最佳实践”合集，可以看作是 Ruby 开发者的“通用语言”，学好了，别人看你的代码就不费劲了。

源代码布局方面

这里说的“布局”，不只是代码好不好看的问题，它直接影响 Git 的 diff 结果，以及跨平台协作的稳定性。

• 编码与缩进：所有源文件统一使用 UTF-8 编码。缩进用 2 个空格，别问为什么用空格不用 Tab，问就是“历史遗留问题”大家都认了。
• 换行符：坚持使用 Unix 风格（n）。Windows 下的 rn 经常导致 Git 把你的文件标记成“全部修改”。可以通过 git config --global core.autocrlf true 来解决。
• 空格的艺术：逗号、分号后面加空格；操作符（指数操作符除外）、花括号前后加空格。但圆括号、方括号后面 不要 加空格。这一点看着琐碎，但能极大提升代码的“呼吸感”。
• 代码层次：case 和 when 要处于同一缩进层级。
• 空行：两个方法（def）定义之间，用一个空行隔开。
• 参数过长：如果一个方法的参数太多，一行写不下，那就该换行换行，参数对齐，别挤在一坨。比如：

def send_mail(source) 
 Mailer.deliver(to: 'bob@example.com', 
         from: 'us@example.com', 
         subject: 'Important message', 
         body: source.text) 
end 

• 文档与长度：用 RDoc 生成 API 文档，注释和方法之间不要有空行。每行尽量别超过 80 个字符，这个老规矩在宽屏时代依然好用，尤其适合做代码 review 和对比。
• 尾随空格：行的末尾不要留空白字符，这属于“细节中的魔鬼”，用编辑器自动清理掉就好。

语法方面

语法是风格的核心，这里讲的是怎么样既“写对”又“写好”。

• 方法括号：无参方法省略括号，有参方法就带上括号，清晰直观。
• 循环控制：尽量别用 for，用 each 来做循环。在 Ruby 里，each 更符合“块”（block）的思维，也更安全。
• 三元操作符：用它替代简单的 if/else 可以让代码更简洁。但千万别在 if/else 内部嵌套三元操作符，那会变成“火星文”。
• when 语句：使用 when X then ... 的写法，因为 when x ... 这种形式在 Ruby 1.9 已经被删除了。
• 布尔与流程控制：做布尔判断时用 && 和 ||；做流程控制时用 and 和 or。这是 Ruby 特有的“低优先级”用法。
• unless 与 else：unless 不要和 else 一起用。这违反了直觉，除非你能保证读者一眼看穿逻辑。
• 装好语句块：多行语句块用 {} 包裹起来，别用 do...end。不过这条在特殊情况下（比如链接方法）可以灵活处理。
• return：不需要用 return 的时候，就别写。Ruby 天然返回最后一个表达式的值。
• 变量初始化：用 ||= 来初始化变量，但注意，不能用来初始化布尔变量（因为 false 也会被替换）。
• Perl 风格：不要使用 $1 到 $9 这种 Perl 风格的变量名，可读性太差。
• 运行检查：运行 Ruby 时，加上 -w 参数，它会提示你代码中潜在的“坏味道”。
• 新语法：使用 Ruby 1.9 及以后版本的语法来写 lambda 和 Hash，比如 -> {} 和 { foo: bar }。

命名规范

命名是代码的“脸面”，一个好的名字能省去一半的注释。

• 变量和方法：用小写字母加下划线命名（snake_case）。
• 类和模块：首字母大写（CamelCase）。
• 常量：全部大写加下划线（SCREAMING_SNAKE_CASE）。
• 布尔方法：返回布尔值的方法，名字后面加个 ？ 后缀。比如 user.active，一目了然。
• 危险方法：有潜在风险的方法（比如修改了自身或退出程序），名字后面加个 ！ 后缀，这是在提醒调用者：“小心，我会改变对象！”

注释

关于注释，其实只有一条真理：代码即注释。如果你的代码够清晰，注释就是多余的。注释应该解释“为什么这么做”，而不是“做了什么”。

类

类是面向对象的基石，Ruby 的动态特性给了我们很多灵活度，但也容易失控。

• 原则：遵循 Liskov 替换原则，子类要能完全替代父类。尽量让类符合 SOLID 原则：单一职责、开闭原则、里氏替换、接口隔离、依赖倒置。
• 方法：为每个类都写一个 to_s 方法，方便调试时查看类的状态。
• 访问控制：多用 attr_reader、attr_writer 这些家族方法来做属性访问控制，别手写 def get_xxx 了。
• 工厂方法：考虑增加一些有意义的工厂方法来做实例初始化，而不是全都塞在 new 里。
• 动态特性：多用 Duck Typing（鸭子类型）而非继承。在动态语言里，多态已经不再是继承的专属。
• 危险变量：避免使用 @@ 类变量和全局变量，它们是潜在的“状态冲击波”。
• 单例方法：使用 self 来定义单例方法，而不是用类名。比如 class << self; def foo; end; end。

异常

异常处理应该像对待地雷一样小心，不要滥用，也不要放任。

• 不要放过：不要捕获异常后什么都不做。
• 不要代替流程：不要用异常来控制程序流程，这是反模式。
• 基类问题：不要捕获 Exception 这个基类，它涵盖了太多你意想不到的错误。
• 排列顺序：捕获多个异常时，按子类到父类的顺序排列。
• 外部资源：所有外部资源（文件、网络连接）的调用，都要放到异常捕获模块里。
• 重用异常：优先使用标准库自带的异常，而不是自己新创建一个类。

集合

集合是日常操作的重灾区，很多坏风格都体现在这里。

• 创建数组：优先使用 %w 来创建字符串数组，比如 %w(foo bar baz)。
• 按需扩容：按需创建数组，不要一开始就声明一个很大的空数组。
• 去重：用 Set 去除列表中的重复元素，有专门的库干嘛不用。
• Hash 的键：用 Symbol 做 Hash 的键，不要用 String。Symbol 比 String 更稳定、更快。也绝对不要用可变对象（比如数组、对象）做键。
• 遍历与修改：千万别在遍历一个列表的同时，又改变它。这会造成不可预期的结果。

Strings

字符串操作看似简单，但写法的差异会严重影响性能。

• 插值：优先使用 "#{string} #{string}" 来做字符串拼接，而不是 String + String。
• 引号：如果字符串里没有使用 #{} 进行插值，就用单引号 '' 表示，省去不必要的解析。
• 实例变量：在做实例变量的连接时，不要使用 {} 包裹，比如 "Hello #@name"。
• 串联：使用 << 而不是 + 来做字符串串联。因为在循环里，+ 会创建大量的临时对象，<< 不会。

正则表达式

正则表达式是“写的时候爽，读的时候哭”的代表作，所以写的时候就要为读的人着想。

• 命名组：使用命名组（(...)）来捕获，而不是使用 $1 到 $9。用名字比用数字好跟踪。
• 锚点：^ 和 $ 是匹配整行；如果要匹配整个字符串，应该使用 A 和 z。
• 可读性：对于复杂的正则表达式，使用 %r 并搭配 x 修饰符，允许注入空格和注释。但要注意空格去除问题。

% 的语法

Ruby 提供了一系列 % 语法糖，用对了省事，用错了徒增迷惑。

• %w：多用它来创建字符串数组。
• %()：当你需要字符串内嵌表达式时使用，比双引号在视觉上更清爽。
• %r：当正则表达式里出现多个 / 时使用，避免转义地狱。
• 少用：不要用 %q、%Q、%x、%W、%s 这些不太常用的形式。记住常用的几个就够了。
• 分隔符：在 % 后面，优先使用 () 作为分隔符，因为它在大多数情况下读起来最自然。

说到底，风格不是“规定”，而是一种“共识”。这份指南的价值在于，当你和一个 Ruby 团队合作时，大家能在这个框架下高效沟通，减少不必要的争执。这，才是真正的生产力。