编写像Ruby的代码

一， Ruby编程风格的核心思想：
1， The first is that code should be crystal clear—good code tells the reader exactly what

it is trying to do. Great code shouts its intent.

十分清楚 ：好的代码准备无误地告诉读者它要做什么。伟大的代码的叫喊出它的意图。

2， The second idea is related to the first:

Since there is a limit to how much information you can keep in your head at any given

moment, good code is not just clear, it is also concise.

第二点与第一点相关。由于我们的大脑中保存的信息量的有限，好的代码不单单要清楚，而且要简洁。

二，In Ruby you indent your code with two spaces per level.

在Ruby中，用两个空格作为每一层次的缩进。

三， There are good reasons for adding comments to your code, the best being to
explain how to use your software masterpiece. These kinds of “how to” comments
should focus on exactly that: how to use the thing.

有很多好理由需要添加注释，最好的理由是怎么使用的你的软件杰作。这些多种多样的“怎么做”应该集中于怎么准确地使用这些东西

四， Ruby also supports multiline comments delimited by =begin and =end, but Ruby programmers
tend to stick with the # style of comments most of the time.

Ruby同时也支持多行注释（通过 =begin =end），但是Ruby程序员大多数时候倾向于使用#风格的注释。

五， Sometimes it’s also wise to include a “how it works” explanation of particularly
complicated bits of code. Again, keep this kind of explanation separate from the “how to”

有时候，对于特别复杂的程序代码也可以包含“它是怎么工作”的注释。 同样的，必须把“怎么工作的”和“怎么使用的”分割开来。

六，The danger in comments that explain how the code works is that they can easily
slide off into the worst reason for adding comments: to make a badly written program

somewhat comprehensible. That voice you hear in your head, the one whispering that

you need to add some comments, may just be your program crying out to be rewritten.
Can you improve the class, method, and variable names so that the code itself tells
you what it is doing? Can you rearrange things, perhaps by breaking up a long method
or collapsing two classes together? Can you rethink the algorithm? Is there anything
you can do to let the code speak for itself instead of needing subtitles?

添加“怎么工作的”注释的危害是很容易滑向添加注释的最差的理由：使得很差劲的代码有点能理解。

一个声音要在你的脑海里回响，当你的代码需要添加注释的时候，也许你的程序正在大声疾呼需要重写。

是否可以通过改变类名，方法名，变量名使得代码自己说明他在做什么？是否可以重新安排事情，也许可以拆分一个长方法或者合并两个类？

是否可以重新思考算法？是否有方法使得代码自我描述而不是需要说明？

七， Remember, good code is like a good joke: It needs no explanation.

记住，好的代码就像笑话，不需要解释。

八， Camels for Classes, Snakes Everywhere Else

类用驼峰风格，其他都用蛇风格。
九，constants should be rendered in all uppercase, punctuated by underscores

常量应该都用大写字母，然后用下划线间隔，如 ANTLERS_PER_MALE_MOOSE = 2

十， With some notable exceptions, Ruby programmers generally vote for the parentheses

除了一些出名的异常外，Ruby程序员基本上选择使用括号。

十一， Ruby programmers do tend to dispense with the
parentheses when calling a method that is familiar, stands alone on its own line, and
whose arguments are few in number.

Ruby程序员倾向于省略括号当调用一个熟悉的方法，这个方法只有一行，并且方法的参数总计很少。

十二， Our old friend puts fits this description to a tee,
and so we tend to leave the parentheses off of calls to puts

我们的老朋友puts方法刚好适合这个描述，所以我们倾向于在调用puts时省略括号。

十三，If you are defining—or calling—a method with no parameters,
leave the parentheses off

当你定义或者调用一个没有参数的方法时，省略括号。

十四， keep in mind that the conditions in control statements don’t require
parentheses—and we generally leave them off

记住在条件控制语句中不需要括号，我们一般情况省略括号。

十五，most Ruby code sticks to the “one statement per line” format

多数的Ruby代码坚持一个语句一行的格式。