Indentation Style

[Nikolai Weibull]

I've been meaning to ask this for quite some time. Why is and
indentation-level of two (2) spaces the standard for Ruby? Is there any
reason for it being so short/small? I've been using eight (8), i.e.
hard tabs, but been feeling it may be a bit too much. But I don't think
I would ever go below 4.
nikolai

 

[Thomas Hurst]

I've been meaning to ask this for quite some time. Why is and
indentation-level of two (2) spaces the standard for Ruby?

This is a common style for GNU projects too. Actually, GNU projects
seem to prefer 2 spaces mixed with tabs for multiples of 8.. retarded
IMO -- if you want to use spaces (heathen!) use spaces, not spaces AND
tabs. Grr.

Is there any reason for it being so short/small? I've been using
eight (8), i.e. hard tabs, but been feeling it may be a bit too much.
But I don't think I would ever go below 4.

I use tabs. Tabs are not eight, tabs are tabs, and are any width you
want them to be; if you can't set your tabstop to 2 and have everything
work properly, you're not indenting well.

Personally I use a ts of 8; it "wastes" space, yes, but it keeps blocks
well seperated and discourages you from getting too deep. At the same
time, anyone can edit my code with their own tabstop and it should
gracefully handle whatever indentation level they prefer.

 

[Ben Giddings]

That is true of any tab size, providing you don't mix spaces in (as noted
above). In fact I tend to use two, but I expand it to four or eight
temporarily is I want to see the block structure more clearly.

You tab-users do make a good argument for tabs, so what happens when you want
to indent a continued argument list, or something else which isn't aligned on
a tab boundary:

module Dumb
class Fake
def do_something?(bar, baz,
bat, buzz)
true
end
end
end

An admittedly contrived example, but hopefully ok for the purposes of
illustration. Many people like that sort of alignment, where if there are
too many arguments for one line, they continue on the next line and line up
with the start of the first argument.

I imagine you'd have 1 tab before "class Fake", 2 before "def do_something..."
and 3 before "true", but what about "bat, buzz"? Can you do it in a way that
the code still lines up if someone changes their tab sizes? I'd guess you
could do two tabs then a bunch of spaces, but it would seem to me that would
be hard to "police".

Personally, I think the most important thing is never to mix tabs and spaces
and since I've had problems with tabs in the past, I never use them at all
now. If you're interested in the topic, Jamie Zawinski has some great info
on his web site about it, including emacs defuns to strip tabs from a file
which contains them.

http://www.jwz.org/doc/tabs-vs-spaces.html

Ben

 

[Michael Garriss]

Tab until you get to the 'right level' (in this case, in line with the
def) then use spaces. This way you can expand and contract the tabs and
still have bat line up with bar. Just remember: tabs before spaces.

 

[Kent R. Spillner]

You tab-users do make a good argument for tabs, so what happens when you want
to indent a continued argument list, or something else which isn't aligned on
a tab boundary:

I defer to the OpenBSD style guide:
$ man 9 style
[SNIP]
for (; {
z = a + really + long + statement + that + needs +
two + lines + gets + indented + four + spaces +
on + the + second + and + subsequent + lines;
}
[SNIP]

Tabs are set to 8; indentation is 1 tab. Then the 4-spaces rule cleanly
sets second-level indentation apart from the rest of the code. "Oh,
hey! That code doesn't appear to be fully indented, so that must mean
it is a continuation of the previous statement."

URL to same (it's loooooong):
http://www.openbsd.org/cgi-bin/man....manpath=OpenBSD+Current&arch=i386&format=html

Ben

-Kent

 

[Johan Persson]

Aren't two spaces the unspoken standard for shell-scripts?

 

[Jim Weirich]

I've been meaning to ask this for quite some time. Why is and
indentation-level of two (2) spaces the standard for Ruby? Is there any
reason for it being so short/small? I've been using eight (8), i.e.
hard tabs, but been feeling it may be a bit too much. But I don't think
I would ever go below 4.

Plaenty of others have weighed in on the style issue and tabs vs
spaces. Prior to Ruby, I would have agreed that 4 spaces was the
minimum indentation level I could live with. However, I tried the Ruby
2-space indentation and came to like it. Now Ruby code with more than
two spaces just doesn't look right. Perhaps its because individual
methods in Ruby are generally shorter, therefore the code doesn't need
greater indentation to set it off.

Try it for a week or two and see if it grows on you. If not, then its
easy enough to switch back.

 

[Sascha Dördelmann]

module Dumb
class Fake
def do_something?(bar, baz,
bat, buzz)
true
end
end
end

An admittedly contrived example, but hopefully ok for the purposes of
illustration. Many people like that sort of alignment, where if there are
too many arguments for one line, they continue on the next line and line up
with the start of the first argument.

I hate this indentation style. I only use it because it seems to be a
kind of standard, at least in the emacs world.

I prefer
def do_something?(
bar, baz, bat, buzz)
true
end

or
def do_something?(
bar, baz, bat, buzz)
true
end

or
def do_something?(
bar, # comment bar
baz, #
bat, #
buzz #
)

I know these are all far from perfect but I dislike anything that
leads to long lines, including tabs. I've seen so much code which
might look fine on a 21' monitor but doesn't fit into smaller screens!

Spaces keep the chosen style. I like that. Code-Editors might handle
spaces and tabs in arbitrary ways. The same isn't true for many other
applications I might want to paste code snipplets into (e. g. a news
reader or a printer).

I also noticed that ruby doesn't allow some of my formatting habits
simply because linebreaks split statements and the ruby interpreter
parses code in a different way as my brain tends to do. ;-)

Cheers
Sascha

 

[Dave Brown]

: > Tab until you get to the 'right level' (in this case, in line with the
: > def) then use spaces. This way you can expand and contract the tabs and
: > still have bat line up with bar. Just remember: tabs before spaces.
: >
: yeah. this is what works for any setting, and allows you to still use
: tabs. the question is, how do you make your editor work this way. Vim
: can't do this (yet).

Yes it does; it's done it for ages.

Put
set softtabstop=2
set tabstop=8
set noexpandtab

in your .vimrc and you'll get what you're asking for.


Now why you'd actually WANT such a thing is beyond me. I use vim
with "set expandtab" at all times because I don't want any tabs in
my code. (Oh, except when I'm editing makefiles. Faugh!)

--Dave

 

[Nikolai Weibull]

: yeah. this is what works for any setting, and allows you to still use
: tabs. the question is, how do you make your editor work this way. Vim
: can't do this (yet).

Yes it does; it's done it for ages.

Put
set softtabstop=2
set tabstop=8
set noexpandtab

in your .vimrc and you'll get what you're asking for.

OMG...read the manual, try it out. see what happens? after you indent
to another tabstop (pressing tab 4 times in succession), you get a tab.
man...and the real issue isn't this, but the way autoindenting works, as
it is mostly responsible for such alignment. what one wants is for each
additional level of indent, add a tab, and for any continuation indent,
use spaces. So, the algorithm would more or less be:
1. Calculate amount of indent for current line.
2. Get level of indent of containing block.
3. Subtract the containing blocks indent from the current line's
and use tabs for it. Indent with spaces for the remaining
indent.

nikolai

 

[Dmitry Borodaenko]

On Mon, Aug 04, 2003 at 05:30:59PM +0900, Sascha D?rdelmann wrote:
SDr> I prefer
SDr> def do_something?(
SDr> bar, baz, bat, buzz)
SDr> true
SDr> end

Ugly: same indentation level for parameters and code sucks ;-)

SDr> or
SDr> def do_something?(
SDr> bar, baz, bat, buzz)
SDr> true
SDr> end

That one is better, but doesn't save you much vertical space anyway, how
about:

def do_something?(bar, baz,
bat, buzz)
true
end

SDr> or
SDr> def do_something?(
SDr> bar, # comment bar
SDr> baz, #
SDr> bat, #
SDr> buzz #
SDr> )

Nice one, but only for the cases where you actually have to comment your
parameters (which probably means you've picked up wrong names),
otherwise it's also a waste of vertical space.

SDr> I know these are all far from perfect but I dislike anything that
SDr> leads to long lines, including tabs. I've seen so much code which
SDr> might look fine on a 21' monitor but doesn't fit into smaller screens!

I've always thought that using more than 80 columns for code editor
window is a waste of desktop space. If it has to look ok on 80 columns
(and I think it has to: 1) that's plenty; 2) that's all you can have in
many cases like console or default terminal window), why waste precious
horizontal space that could be used for debug output, class browser, or
one more code window?

SDr> Spaces keep the chosen style. I like that. Code-Editors might
SDr> handle spaces and tabs in arbitrary ways. The same isn't true for
SDr> many other applications I might want to paste code snipplets into
SDr> (e. g. a news reader or a printer).

Hear, hear!

SDr> I also noticed that ruby doesn't allow some of my formatting habits
SDr> simply because linebreaks split statements and the ruby interpreter
SDr> parses code in a different way as my brain tends to do. ;-)

Try using '\' at the end of such lines ;-)

 

[Francis Hwang]

One thing that hasn't been brought up in this discussion is that a lot
of this has to do with how big you like your text to be on the screen.
If you're editing text with your text-size set to 8-point Courier or
something, then it's fairly difficult to see two spaces. Personally, I
set my monitor resolution as high as it goes (paying attention to
refresh rate) and then in BBEdit I view all files in Courier 18, so
individual letters are big and chunky and a 2-space tab is quite easy
to see.

It's a tradeoff. You want to be able to see as much text as possible
but you also don't want to strain to see it. I err towards really big
characters because I think small fonts make you strain without you
realizing it. If you look around any office at any random point you'll
see that half the people are subconsciously squinting and leaning into
the monitor, which is quite bad for your neck, shoulders, and back.

I've spent a lot of time and money over the last few years dealing
with injuries caused by bad ergonomics, so obviously this sort of
thing is on my mind quite a bit ...

Francis