From: Daniel Finnie <danfinnie@...>
Date: 2007-01-10T08:40:59+09:00
Subject: Re: [ANN] Elements of Ruby Style

I think that's a good idea, but I have some questions about some items:

2.b.vi. If a your method has a block parameter, try to use yield rather 
than accepting it as a variable and calling call on it.
--> What is the reasoning behind this?  I'm not trying to criticize (yet 
;-), but it seems like The Ruby Way is not doing this.  For example, $_ 
= "hollywood"; scan(/o/); isn't preferred over "hollywood".scan(/o/).

2.b.viii and 2.b.x seem to be very similar, perhaps merge them?

2.c.ii says "curly braces" while 2.c.i just says "braces."  Also, what 
if you want something's return value but you do it on multiple lines? 
Either that never happens, so the rule isn't necessary, or it happens 
and then you have a conflict in the rules.

2.e.i Use try catch to control flow rather than rescue blocks
--> Do you mean catch/throw?  I don't recall a try/catch in Ruby and a 
quick Googling finds nothing.

2.f I think a lot of these need some example code (before and after). 
What is a statement modifier?  &&, !, etc?

2.h.i   There is no advantage to using single quotes or double quotes 
other than safety
--> Double quotes allow interpolation and have more escape sequences. 
What is "safety" in this context?

2.h.ii Don���t combine string literals and variables using +; rather, 
use interpolation
--> What if I want to append something to an existing string?  Should I 
use existingString = "#{existingString}#{newString}" or existingString 
<< newString?  (Or +=?)

2.h.iii I think a previous email went over this.

3.b.i Should have an example.

3.b.v Is a repeat of 2.g.i, although maybe it is important enough to be 
repeated!

Jeremy McAnally wrote:
> Hello all,
> I'm happy announce a project that I've been working on for a little while.
> 
> I've noticed that a lot of posts on the mailing are "what's the most
> rubyish way to do (x)?" where x could be transversing a file and
> matching regexes to looping through records in a database to switching
> between two logic branches.  So, seeing this, I thought, why not give
> these people a refernece?  Instead of having to type out a long answer
> every time, why not give them a Fine Manual to read?
> 
> So I began work on Elements of Ruby: a descriptive style manual, that
> is, that this manual will only describe the typical style used in the
> language, and should not be used as a way to prescribe style. I want
> it to be used as a learning tool and to answer questions about the
> best style in a given situation rather than to spawn religious
> arguments about style.
> 
> The problem is that I havent gotten very far yet (darn you holidays
> and book deadlines! ;)).  Actually, that's why I'm posting here: I
> need your help.  I've managed to build a small list of items so far
> (viewable at http://www.elementsofrubystyle.com/ ), but I want to add
> more.  So I thought I would open discussion here for input.  I want it
> to be useful to everyone, so everyone should have some input, yes?
> 
> I have a Rails applicatio built to power it, but I want to nail down a
> fairly final list of things before I populate its database and deploy
> it.  After it's deployed, then you will be able to submit comments on
> each element (e.g., to voice an exception or add to it) and submit
> examples for each one (that will be integrated and properly
> attributed) or suggest new things to be added/changed.
> 
> Anyhow, look at the list, and let's talk about what should be on there.
> 
> Visit http://www.elementsofrubystyle.com/ .
> 
> --Jeremy
>