Any guides for good coding in Ruby?

[Nikolai Weibull]

* Sam Roberts (Mar 23, 2005 00:50):

That's funny, I haven't found that emacs uses spaces to indent by
default. Its supposed to default to the GNU coding standard, though
what it does on any machine is pretty subject to the whims of who
installed it. The emacs standard/GNU indent style is the weirdest
around, IMO.

Yes, but you aren't using it in your example:

foo()
{
int ;

if()
{
...

That would be

<type>
foo(void)
{
int i;

if (<test>)
{
...
}
}

And there is a good reason for doing it that way: the name of the
function appears in column one, making it easy to grep for and for
certain utilities to parse the file. The default
indent-size is two spaces, as can be seen in the third line and also
note how the curly-brackets are in column 1 for a function body. For
the if, the bracket-group is the statement associated with and inside
it, code is indented another level. See how consistent it is? See how
the bracket-delimited block is indented like a single statement to the
if would have been? It's very, very consistent. It's also very, very
ugly.

It uses TAB by default (every time indent gets over 8 chars, it uses a
TAB). I've always though the GNU coding style was specified to showcase
the power of the emacs indentation engine. I never got vim to do it, but
I just fed my functions through GNU indent, and whatever it looked like,
I comitted. Can't be acused of not following the GNU coding standards
then, GNU indents output is supposed to follow it!

It's very easy to do with vim. Simply leave your 'ts' alone, set 'sw' to
8, don't set 'sts' and don't set 'et'. Those are all default settings
by the way.

GNU indent can be set to use any of a variety of indentation
"standards". It can also be configured to your hearts delight.

I'm averse to indents over about 4, and I think tabs are lame. They work
fine if everybody on your team uses the same settings, but when anybody
else looks at your code, it will look bad.

In a perfect world, people would actually use tabs appropriately. Until
they do, the best solution is to not use them,
nikolai

 

[vruz]

I can't decide if it's just the example or the whole section, but this

one just doesn't feel right to me. I would much rather have a class
rendering itself (who better qualified?), then providing accessor like
data for others to do it. Push, don't pull, right?

I see what you mean, and I agree with you about that particular
section. ( also, it's especially noted in the title that is not a
specific Ruby idiom.)

I believe that this pattern may well be domain-specific to a certain
technique of graphics rendering, and that's probably not the best
place to put that piece of code.
(but it's a wiki, you know...)

wrt that specific section, I would also argue that I can barely see
the need for abstract classes like that in any Ruby code.

An excellent book on this topic is Holub on Patterns, if you're
interested.
Anyway, just wanted to share. I really did love the page.

Thank you for the recommendation.
cheers,
vruz

 

[Ben Giddings]

It's very easy to do with vim. Simply leave your 'ts' alone, set 'sw' to
8, don't set 'sts' and don't set 'et'. Those are all default settings
by the way.

And people say vi isn't intuitive!

In a perfect world, people would actually use tabs appropriately. Until
they do, the best solution is to not use them,

Yeah, I agree.

Ben

 

[Nikolai Weibull]

* James Edward Gray II (Mar 22, 2005 23:50):

Amen! I don't know who thought up the two space thing, but they were
out of line. In Ruby, you don't even need the extra characters to
keep lines short, generally. I'm set tabs to four spaces wide, but
it's definitely tabs all the way.

Messing with the width of tabs is always crazier than using two-space
indents.

I don't see why you would need the extra indent in Ruby anyway, it's
pretty clear without the additional horizontal whitespace.

I began writing Ruby-code with an eight-space tab indent, but it made my
code look chubby (it was wider than it was long).

And while we're getting things off our chest, it really bugs me when
people don't keep their code within the 80 character boundary
guideline. I've been reading all the links posted in this thread and
they've all recommended it, but I can sure tell you from running Ruby
Quiz that not everyone is listening.

Actually, for the Quiz, 72 would be a better limit, as that works best
for mails.

Seriously, though, the 80 character boundary is a thing of the past.
Terminals (not to mention emulators) can be made wider, 132 being a good
"standard" setting, so it's not even about backwards compatibility
anymore. I find that I can write code the way I want it if I'm not
constrained to 80 characters per line. (I only switched to a
132-character-wide terminal about 3 months ago, though, so I may change
my mind yet again.),
nikolai

 

[Nikolai Weibull]

* Eric Schwartz (Mar 23, 2005 01:00):
I agree with you in this instance. It does depend on the setting,
though.

If you have a class just providing data for others to render then you
can much more easily implement renderers than if you have to modify
your data class for each format you care to render it into.

Actually, the best way to solve this problem would be to use the Visitor
pattern, right?,
nikolai

 

[Nikolai Weibull]

* Ben Giddings (Mar 23, 2005 01:10):

And people say vi isn't intuitive!

well, I could have spelled them out, but that wouldn't have changed
much ;-). (The full command is
:set tabstop& shiftwidth& softtabstop& expandtab&
by the way),
nikolai

 

[Swaroop C H]

well, I could have spelled them out, but that wouldn't have changed
much ;-). (The full command is
:set tabstop& shiftwidth& softtabstop& expandtab&
by the way),

You forgot to include 'smarttab'

 

[Jim Freeze]

* James Edward Gray II (Mar 22, 2005 23:50):

Messing with the width of tabs is always crazier than using two-space
indents.

Boy, I don't know where all this came from, I thought the majority
were all on the same page, but maybe it is because of
all the new people. Maybe we should have a coding standard
linked from ruby-lang.

One problem with tabs is that people tend to mix tabs and spaces,
then, when I set the tab to be 2-spaces, I may get 2,3 or 4 spaced
indents.

 

[Sascha Ebach]

Nice to have so many experts here I have actually been fighting
around with this issue. I have found that using tabs always gives me
headaches somewhere. For example when I paste code examples into emails.

What do I have to set in vim if I always want two spaces (also when I
press the tab key)? No exceptions. I essentially want this:

class PageController
def edit
case @request.method
when :get
@page = Page.find(@params['id'])
when ost
...
end
end

Sascha

 

[Nikolai Weibull]

* Jim Freeze (Mar 23, 2005 01:30):

One problem with tabs is that people tend to mix tabs and spaces,
then, when I set the tab to be 2-spaces, I may get 2,3 or 4 spaced
indents.

There's no good reason to change the width of tabs. Your editor should
be able to emulate this behaviour anyway. In vim, to get two-space
indents:

:set softtabstop=2 shiftwidth=2

or

:set sts=2 sw=2

if you're lazy, and leave the 'tabstop' setting alone,
nikolai

 

[James Edward Gray II]

Actually, for the Quiz, 72 would be a better limit, as that works best
for mails.

Seriously, though, the 80 character boundary is a thing of the past.

All space and tab holy war fun aside, I strongly disagree on this point
and would like a chance to plead my case. Here's some food for
thought: If it's so in the past, why does almost everyone still
recommend it?

The truth is that is has nothing to do with terminals anymore, in my
not at all humble opinion. You've just pointed out a great reason
above: email clients. Here's another one: Web pages. 90% of the
problems I have with the current Ruby Quiz site are that the code often
overflows the boxes. I hand edit each and every chunk of code in a
never-ending battle against this. I'm trying to come up with a good
solution for it in the Ruby Quiz 2.0 site, but that's harder than it
sounds. I want the new site to include the code as that'll open up a
lot of exciting options, but I have to figure out how to do this
realistically first and this issue is the biggest hurdle.

Ironically, I still don't think those are the biggest reason to do it.

I believe the number one reason you should still keep code at 80
characters per line is to help authors put your work in their books.
It just so happens that a typical programming book with reasonable
fonts and light indenting of the code examples has darn near 80
characters of space to play with. You do want everyone writing about
your code don't you? I bet you'll shorten that margin back up when you
begin writing your first masterpiece.

To summarize, it isn't just about terminals. Be kind to your email
reader, webmaster, and author. Stick with 80.

James Edward Gray II

 

[Nikolai Weibull]

* Swaroop C H (Mar 23, 2005 01:30):

You forgot to include 'smarttab'

Hm, well, true, leave smarttab at its default setting (of off) as well,
nikolai (the “who the hell messes with the smarttab
setting?â€-kinda guy)

 

[Nikolai Weibull]

* Sascha Ebach (Mar 23, 2005 01:30):

Nice to have so many experts here I have actually been fighting
around with this issue. I have found that using tabs always gives me
headaches somewhere. For example when I paste code examples into emails.

What do I have to set in vim if I always want two spaces (also when I
press the tab key)? No exceptions. I essentially want this:

class PageController
def edit
case @request.method
when :get
@page = Page.find(@params['id'])
when ost
...
end
end

What? You want tab to equal two spaces, regardless of column? Then,

:imap <Tab> <Space><Space>

is what you want, but, again, are you sure that's what you want?,
nikolai

 

[Ben Giddings]

That's funny, I haven't found that emacs uses spaces to indent by
default. Its supposed to default to the GNU coding standard, though what
it does on any machine is pretty subject to the whims of who installed
it. The emacs standard/GNU indent style is the weirdest around, IMO.

Yeah, I don't like its default behaviour. I very rarely use emacs
without a .emacs file that overrides this. It's pretty easy:

In your .emacs file:

(setq indent-tabs-mode nil)

Or from within emacs: "M-x customize-option" "indent-tabs-mode" and
choose off (nil).

Or at any point for a given session: "M-x set-variable"
"indent-tabs-mode" "nil"

I'm averse to indents over about 4, and I think tabs are lame. They work
fine if everybody on your team uses the same settings, but when anybody
else looks at your code, it will look bad.

Or when you look at it in a web browser, which can't (afaik) be
customized, etc. etc.

I think a bunch or ruby core developers (matz, for one) use emacs, so
many of the files use tabs, and indent two char widths per nesting
level. Not all, though.

Maybe if we keep this off-topic thread going long enough they'll fix
their editors just to shut us up.

Ben

 

[Nikolai Weibull]

* James Edward Gray II (Mar 23, 2005 01:40):

All space and tab holy war fun aside, I strongly disagree on this
point and would like a chance to plead my case. Here's some food for
thought: If it's so in the past, why does almost everyone still
recommend it?

The truth is that is has nothing to do with terminals anymore, in my
not at all humble opinion. You've just pointed out a great reason
above: email clients. Here's another one: Web pages. 90% of the
problems I have with the current Ruby Quiz site are that the code
often overflows the boxes. I hand edit each and every chunk of code
in a never-ending battle against this. I'm trying to come up with a
good solution for it in the Ruby Quiz 2.0 site, but that's harder than
it sounds. I want the new site to include the code as that'll open up
a lot of exciting options, but I have to figure out how to do this
realistically first and this issue is the biggest hurdle.

As I said, 72 would be a better limit for the Quiz.

Ironically, I still don't think those are the biggest reason to do it.

I believe the number one reason you should still keep code at 80
characters per line is to help authors put your work in their books.
It just so happens that a typical programming book with reasonable
fonts and light indenting of the code examples has darn near 80
characters of space to play with. You do want everyone writing about
your code don't you? I bet you'll shorten that margin back up when
you begin writing your first masterpiece.

How often is this the case? I have yet to see a book displaying
snippets of code from actual software beyond showing of horrible coding
practices (perhaps a good reason to stay within the 80-characters-per-
line limit, as you don't want to end up in one of those books).

I know Holub on Patterns is an exception (a book you seem to hold very
dear), as it is more or less a "patterns in the wild"-kinda book.
Still, not many books are written that way. Most write the code for the
book, not the other way around.

To summarize, it isn't just about terminals. Be kind to your email
reader, webmaster, and author. Stick with 80.

Be kind to yourself: expand your horizon,
nikolai

 

[James Edward Gray II]

How often is this the case? I have yet to see a book displaying
snippets of code from actual software beyond showing of horrible coding
practices (perhaps a good reason to stay within the 80-characters-per-
line limit, as you don't want to end up in one of those books).

I believe this is one of the design goals of the new Facets of Ruby
series.

James Edward Gray II

 

[Phil Tomson]

Yay! Let's start a tabs vs. spaces flame war!!

My view? Tabs should never, ever be used in a file. (Ever) Can you
have a source code file without spaces? I doubt it. Can you have a
file without tabs? Certainly. Is mixing the two the main problem?
Yup. Use only spaces.

Amen. and I am a vi user (see below).
The lucky thing for us Ruby users is that the number of spaces/tabs (while
the two might look the same on the screen) doesn't matter to the
interpreter as it does with another language that starts with a P.

It's funny though. I think this eternal flame war is related to the
other eternal flame war: vi vs. emacs. In Emacs, the 'tab' button is
most often bound to 'indent-command'. This and 'indent-region' makes it
really easy to use spaces for indentation, and to adjust/fix someone
else's indentation when it's bad. On the other hand, I think vi makes
it much harder to use spaces for indentation, so tabs seem more attractive.

Actually, there are autoindent modes for vim - there's one for Ruby code.

Phil

 

[Timothy Hunter]

To summarize, it isn't just about terminals. Be kind to your email
reader, webmaster, and author. Stick with 80.

The 80 char limit never was about terminals. It was about punched cards.

 

[Nikolai Weibull]

* James Edward Gray II (Mar 23, 2005 02:20):

I believe this is one of the design goals of the new Facets of Ruby
series.

True, true. Still, it's not very hard to format existing code to fit
within an 80-character limit. There are definitely harder, more
time-consuming, things to writing a book,
nikolai

 

[Sascha Ebach]

* Sascha Ebach (Mar 23, 2005 01:30):

Nice to have so many experts here I have actually been fighting
around with this issue. I have found that using tabs always gives me
headaches somewhere. For example when I paste code examples into emails.

What do I have to set in vim if I always want two spaces (also when I
press the tab key)? No exceptions. I essentially want this:

class PageController
def edit
case @request.method
when :get
@page = Page.find(@params['id'])
when ost
...
end
end

What? You want tab to equal two spaces, regardless of column? Then,

:imap <Tab> <Space><Space>

is what you want, but, again, are you sure that's what you want?,

Yes, I think so. I cannot remember that I really need a tab in any
programming language I have used. If I need a tab in my strings I can
simply do a "\t". Do you know of any circumstance you actually _need_ a tab?

Sascha