Ruby editing style rules and recommendation?

Ruby
1

I asked a question ‘Decimal in for loop?’ and two members were kind
enough to solve this problem. Thanks, Fleck and Aaron.

Now I have another question: Are there any editing style rules and
recommendations in Ruby?

In the previous thread, Fleck wrote:

0.step(0.5,0.1) { |i| p i }

while Aaron wrote:

(0…0.5).step(0.1) do |f|
p f
end

and both work identically.

Which one is recommended in terms of the editing style?

In C++, for example, I use Ellemtel rules
(Programming in C++, Rules and Recommendations)
. Emacs supports editing assistance in this style particularly
auto-indent. . . I’m sure that Emacs supports the similar feature in
Ruby too because Matz loves Emacs! Please advise.

Thanks,
Nathan

2

El Sábado, 9 de Enero de 2010, Nathan O. escribió:

and both work identically.

Which one is recommended in terms of the editing style?

Imho using { } for inline code and do…end for a multiline block of
code. This
is:

Correct:

array.each do |entry|
lalala = entry.name
lololo = entry. time
end

Correct:

array.each { |entry| lalala = entry.name }

“Incorrect”:

array.each { |entry|
lalala = entry.name
lololo = entry. time
}

“Incorrect”:

array.each do |entry| lalala = entry.name ; end

3

I will just echo what was said so far, in regards to whatever fits the
situation. I am a novice myself, and have bounced between several
languages for several reasons. I am hoping to stick with Ruby now
because things are so much more focused on writing the program to do
what you want, and not what the compiler wants, etc. (Or so Ruby
claims as a goal)

I find this especially helpful for readability. I think, especially
if you are expecting others to be reading your code, or you have a
hard time even reading your old work, the best thing is to always code
for readability; unless the situation absolutely demands you
compromise for speed and/or efficiency. In Ruby it doesn’t seem like
speed is necesarrily a priority as it is, due to the nature & maturity
of the language thus far (1.9 seems to be a big step up though). So
why note just code for readability down the road? As long as you’re
not being offensively verbose, or anything…

As a new programmer, I am hoping to teach myself this early on, so it
doesn’t become an issue down the road. At first I hated the idea of
commenting almost everything I did in any language, but soon found
that (of course) it was a very big help to explain what problem I was
trying to solve, or why I chose to use a particular code block to do
it.

After discovering Ruby, my appreciation for readable code even went a
little further. Although I don’t think its perfect, or exceptional
beyond most other languages, it does seem to place a heavy emphasis on
keeping things simple, and easy to understand.

I think the best approach is to first, keep it readable. Then
comment it appropriately. If you are the primary reader of your own
code, and you find one style of writing a statement to be easier for
you to understand, then just write it out that way, unless you
absolutely have to do it another way that might result in better
performance for whatever reason. Likewise, if you are anticipating
others needing to view your work, do as mentioned, but also take
extra care to make sure your code is commented properly enough so that
someone else understands the purpose of the code.

Sorry if this sounds a little redundant or obvious, but I don’t think
there is really any one “perfect” way to write code. It is nice to
have guidelines and standards, to help keep things organized and
understood between people, but at the end, it is also about what
makes you more efficient with your time and effort. If its easier
for you to do something one way, that’s all there is to it. Just
keep it balanced with good documentation and internal comments.

-Zach

On Sat, 9 Jan 2010 15:01:51 -0500, Nathan O. [email protected]

4

On Sat, Jan 9, 2010 at 3:01 PM, Nathan O. [email protected] wrote:

while Aaron wrote:
(Programming in C++, Rules and Recommendations)
. Emacs supports editing assistance in this style particularly
auto-indent. . . I’m sure that Emacs supports the similar feature in
Ruby too because Matz loves Emacs! Please advise.

Here’s my two cents

http://talklikeaduck.denhaven2.com/2007/10/02/ruby-blocks-do-or-brace

–
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: Rick DeNatale - Developer - IBM | LinkedIn

5

On Sat, Jan 9, 2010 at 2:01 PM, Nathan O. [email protected] wrote:

Which one is recommended in terms of the editing style?

I usually use braces for single line, and do/end for multi-line.

I’ve also started alternating them to make it clearer where blocks start
and
end.

def whatever
each { |obj|
if obj < MID
call_method
else
self.var = yield obj
call_other_method
end
}
end

def whatever
each do |obj|
if obj < MID
call_method
else
self.var = yield obj
call_other_method
end
end
end

I think the top one is much easier to read, so I sometimes alternate
now.

6

Josh C. wrote:

On Sat, Jan 9, 2010 at 2:01 PM, Nathan O. [email protected] wrote:

Which one is recommended in terms of the editing style?

I usually use braces for single line, and do/end for multi-line.

That’s what 99% of Ruby programmers do. :slight_smile:

I’ve also started alternating them to make it clearer where blocks start
and
end.

def whatever
each { |obj|
if obj < MID
call_method
else
self.var = yield obj
call_other_method
end
}
end

Yuck! That looks inconsistent to me. It would also be an editing
nightmare if you extract or introduce one level of nesting.

def whatever
each do |obj|
if obj < MID
call_method
else
self.var = yield obj
call_other_method
end
end
end

I think the top one is much easier to read, so I sometimes alternate
now.

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

7

On 09.01.2010 21:01, Nathan O. wrote:

while Aaron wrote:

(0…0.5).step(0.1) do |f|
p f
end

and both work identically.

Which one is recommended in terms of the editing style?

Whatever fits the situation. No, really. If the {…} block form fits in
an instance, you use that. If the do…end block form fits, you use that
instead.

Caveat: The latter is most common if you deal with a multi-line block:

a_block do |x|
puts x
x += 1
end

Otherwise:
Indents are two spaces. Not tabstops of length 2, but the actual
character (" ").

And once you have written enough Ruby, you’ll know what “feels” correct
to you.

8

Thanks, your all are really helpful!
As a newbie, I will try to write Ruby codes as NORMALLY as possible :slight_smile:

9

On Sat, Jan 9, 2010 at 8:34 PM, Marnen Laibow-Koser
[email protected]wrote:

  call_other_method
end

}
end

Yuck! That looks inconsistent to me. It would also be an editing
nightmare if you extract or introduce one level of nesting.

It’s not mandatory, it’s mostly just whether they can be lined up
easily.
Meaning I would do it if I were having difficulty reading it, so at that
point it can be expected to save me time. If the level of nesting
changes,
that doesn’t translate into a change between braces and do/end, only if
the
introduction makes it difficult to read (meaning they alternate based on
readability rather than every other level of nesting).

10

Marnen Laibow-Koser wrote:

Josh C. wrote:

def whatever
each { |obj|
if obj < MID
call_method
else
self.var = yield obj
call_other_method
end
}
end

[…] It would also be an editing
nightmare if you extract or introduce one level of nesting.

Why?

How would you usually add one level of nesting there? (perhaps I could
learn an editing trick.)

11

On Mon, Jan 11, 2010 at 12:49 AM, Albert S.
[email protected]wrote:

Why?

It makes it conspicuous where everything begins and ends, you don’t have
to
analyze anything to figure it out.

How would you usually add one level of nesting there? (perhaps I could
learn an editing trick.)

I don’t think I understand the question, you write it the same way you
normally would, you just replace some do/end with brackets, where they
make
it easier to follow. The criteria are subjective.

I’m not sure what you mean by an editing trick, presumably you’re
thinking
as Marnen did, that adding a level obligates me to swap anything back
and
forth. I don’t consider that to be the case, it’s not a rule, it’s just
something I do to clarify my code, sometimes I find two do/end pairs
between
every bracket is easiest to read, it just depends. But if you’re in
TextMate, you can do ctrl+{ to swap back and forth. It seems to work
okay,
but is a little buggy, so I don’t use it often.

12

On Sat, Jan 9, 2010 at 9:01 PM, Nathan O. [email protected] wrote:

0.step(0.5,0.1) { |i| p i }

while Aaron wrote:

(0…0.5).step(0.1) do |f|
p f
end

Which one is recommended in terms of the editing style?

Whichever makes the code more readable in each situation.

I tend to use braces/{ } in functional-style code and do/end in
imperative-style code.

For example, I usually use braces with
Enumerable#map/select/delete_if/find/sort, and do/end with
Enumerable#each, File#open and Thread#new.