Indentation Style

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

···


::: name: Nikolai Weibull :: aliases: pcp / lone-star :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,php,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)[“have”]+“fun”-97);}

Hi,

···

In message “Indentation Style” on 03/08/02, Nikolai Weibull lone-star@home.se writes:

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?

Just because I felt too much indentation is like wasting horizontal
space. Two spaces are smallest yet non confusing level of
indentation. YMMV.

						matz.

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.

···
  • Nikolai Weibull (lone-star@home.se) wrote:


Thomas ‘Freaky’ Hurst - freaky@aagh.net - http://www.aagh.net/

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.

···

On Sat, 2003-08-02 at 08:16, Nikolai Weibull wrote:

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.


– Jim Weirich jweirich@one.net http://onestepback.org

“Beware of bugs in the above code; I have only proved it correct,
not tried it.” – Donald Knuth (in a memo to Peter van Emde Boas)

Mee, too. I set tabstop=4 in vim. 2 spaces makes it hard for me to
follow the code.

···

On Sat, 2 Aug 2003, Nikolai Weibull wrote:

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


::: name: Nikolai Weibull :: aliases: pcp / lone-star :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,php,war3 :::
main(){printf(&linux[“\021%six\012\0”],(linux)[“have”]+“fun”-97);}

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

Nikolai Weibull lone-star@home.se wrote in message news:20030802121606.GA2615@puritan.pcp.ath.cx

···

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

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.

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.

···

On Sat, 2 Aug 2003 23:02:08 +0900 Thomas Hurst tom.hurst@clara.net wrote:

  • Nikolai Weibull (lone-star@home.se) wrote:


Thomas ‘Freaky’ Hurst - freaky@aagh.net - http://www.aagh.net/


Seth Kurtzberg
Research, Development, and Network Operations Center
ISEC.us
480-314-1540
seth@isec.us

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

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

···

On Sat August 2 2003 1:01 pm, Seth Kurtzberg wrote:

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.

There is no need for any additional code or info for emacs to strip
tabs. emacs has the built in command “tabify” and “untabify”

And, in fact, if you set up emacs to use tabs, emacs will use spaces to
get to a column which isn’t a tab column; it will simply use the
maximum number of tabs and then the minimum number of spaces.

So Ben’s issues really don’t exist as far as I can tell.

However, since it is so easy to convert back and forth (tabs to spaces,
spaces to tabs) in emacs, one can certainly leave this as a matter of
personal preference.

···

On Saturday, August 2, 2003, at 11:04 AM, Ben Giddings wrote:

On Sat August 2 2003 1:01 pm, Seth Kurtzberg wrote:

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.

Tabs versus Spaces

Ben


Seth Kurtzberg
CTO
ISEC Research and Network Operations Center
480-314-1540
888-879-5206
seth@isec.us

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.

Ben Giddings wrote:

···

On Sat August 2 2003 1:01 pm, Seth Kurtzberg wrote:

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.

Tabs versus Spaces

Ben

Ben Giddings wrote:

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 (;:wink: {
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.cgi?query=style&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

Ben

-Kent

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. :wink:

Cheers
Sascha

···

Ben Giddings ben@thingmagic.com wrote:

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.

Vim can do this too of course. In a large development group (like open
source) you just have to adjust the tab/space thing yourself before you
start working.

Seth Kurtzberg wrote:

···

There is no need for any additional code or info for emacs to strip
tabs. emacs has the built in command “tabify” and “untabify”

And, in fact, if you set up emacs to use tabs, emacs will use spaces
to get to a column which isn’t a tab column; it will simply use the
maximum number of tabs and then the minimum number of spaces.

So Ben’s issues really don’t exist as far as I can tell.

However, since it is so easy to convert back and forth (tabs to
spaces, spaces to tabs) in emacs, one can certainly leave this as a
matter of personal preference.

On Saturday, August 2, 2003, at 11:04 AM, Ben Giddings wrote:

On Sat August 2 2003 1:01 pm, Seth Kurtzberg wrote:

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.

Tabs versus Spaces

Ben


Seth Kurtzberg
CTO
ISEC Research and Network Operations Center
480-314-1540
888-879-5206
seth@isec.us

That identation style, with which I have no disagreement, has
absolutely nothing to do with the issue of spaces vs. tabs.

···

On Saturday, August 2, 2003, at 11:28 AM, Kent R. Spillner wrote:

Ben Giddings wrote:

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 (;:wink: {
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.cgi?query=style&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i3
86&format=html

Ben

-Kent


Seth Kurtzberg
CTO
ISEC Research and Network Operations Center
480-314-1540
888-879-5206
seth@isec.us

And, in fact, if you set up emacs to use tabs, emacs will use spaces to
get to a column which isn’t a tab column; it will simply use the
maximum number of tabs and then the minimum number of spaces.

Right, but then that breaks my example because it would insert more than 2
tabs before “bat, buzz)”

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

Change tab size to 8

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

The above is what you’d want, but if it had inserted the maximum number of
tabs before using spaces when tabs were size 2, then you’d have problems,
like bat/buzz going way off to the side.

However, since it is so easy to convert back and forth (tabs to spaces,
spaces to tabs) in emacs, one can certainly leave this as a matter of
personal preference.

There are two scenarios:

  1. “bat, buzz” is lined up with 2 tabs then as many spaces as necessary to
    indent it properly
  2. “bat, buzz” is indented with the maximum number of tabs, then as many
    spaces as needed to fill in

Number 1 works when tab size is changed, but number 2 doesn’t. As far as I
can tell, emacs does #2 when you hit the “tab” key, so unless you indent
manually, code using tabs won’t be portably aligned.

If I had the freedom to hit the “tab” key and have it “do the right thing”
while using the tab character, I’d use tabs, but it doesn’t, so I’ll stick
with spaces. I guess the only real solution to this is the python solution:
if it isn’t indented right, it doesn’t work… but I think I’ll stick with
Ruby.

Ben

···

On Sat August 2 2003 2:09 pm, Seth Kurtzberg wrote:

On Sun, 3 Aug 2003 03:28:18 +0900, “Kent R. Spillner”
kent@zerosphere.org wrote (more or less):

Ben Giddings wrote:

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 (;:wink: {
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.”

It sounds to me like what they actually want is a ‘1/2 tab’ fo
continuation lines, and that way they could continue to get teh
benefit mentioned earlier in the thread of altering tabs sizes as and
when they see fit - say 2 spaces big normally, 8 spaces big when
examining code structure.

Given that tabs are atomic, I’d then start using
2 tabs = 1 level of indent
1 tab = continuation line.

Mind you, if you then keep to Matz’ standard, then 1 tab would = 1
space… :slight_smile:

Cheers,
Euan
Gawnsoft: http://www.gawnsoft.co.sr
Symbian/Epoc wiki: http://html.dnsalias.net:1122
Smalltalk links (harvested from comp.lang.smalltalk) http://html.dnsalias.net/gawnsoft/smalltalk

The problem here is that the alignment depends on your local settings
for tab expansion. If the reader or maintainer of your code uses a
different amount of spaces the style gets messed in his editor.

Spaces seem to be the only solution for portable (among editors) source
code.

– fxn

···

On Saturday 02 August 2003 20:10, Michael Garriss wrote:

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.

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). I guess it wouldn’t be very painful to add though.
nikolai

···


::: name: Nikolai Weibull :: aliases: pcp / lone-star :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,php,war3 :::
main(){printf(&linux[“\021%six\012\0”],(linux)[“have”]+“fun”-97);}

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

Ugly: same indentation level for parameters and code sucks :wink:

or
def do_something?(
bar, baz, bat, buzz)
true
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

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

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.

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!

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?

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).

Hear, hear!

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. :wink:

Try using '' at the end of such lines :wink:

···

On Mon, Aug 04, 2003 at 05:30:59PM +0900, Sascha D?rdelmann wrote:


Dmitry Borodaenko