Using TABs vs. spaces II. (the Philosophy flamewar reloaded

Ruby
1

Hello,

I read somewhere that good-style Ruby code is indented by 2 spaces. I’d
like
to tell you my problem: I’m not disabled, but I have problems with
reading
code if the indentation is only at 2 spaces. I must indent more. It’s
all
about my dysfunction of reading.

The main argument for using spaces is that the code looks everywhere
same.
But - who needs it? From my point of view, I don’t care if the code
looks
same on my and on my friend’s computer.

Of course, I expect the code to look same on my computer. There is a
problem:
Unfortunately GNU/TAB is set to 8 characters and if you display code on
terminal, for example using diff or grep, it’s not well readable and may
look
different than in your editor. So it breaks what I wrote above about
same-looking code within one computer. I don’t know if there is any
solution
for this case or if TAB length is hardcoded in Linux/BSD kernel.

from Linux coding style:
“In short, 8-char indents make things easier to read, and have the added
benefit of warning you when you’re nesting your functions too deep.
Heed that warning.”

On the other hand, terminal vs. editor difference is not fatal. I still
can
better read more-indented code than less-idented code. I use vim-diff
and
when I grep something, the grep output usually looks like a big mess and
I
really don’t care about indentation :slight_smile: Moreover, I spend much more time
programming than grepping, and that’s why…

That’s why I prefer TABs. The main purpose of TABs is - to indent. I
don’t
think it is archaic. Almost all good editors are able to set indentation
today, so everyone can set indent him/herself at pleasure. The code will
still look consistent on other’s computer even if different indentation
is
used there. If you indent using spaces, you can’t set it alternatively
(if
you don’t want to do recoding, which is bad idea).

There always be people who will need more indents because of their worse
recognition capability and they can do it thanks to TABs.

(Another con of TABs is editing code in editors which aren’t able to set
indenation (notepad). But. Do you usually use notepad for programming?
(Hmm.
(…))

Of course, when I use TABs, I have to follow this rule: Don’t use TABs
elsewhere just before first non-space character on a line. It means
don’t mix
TABs with spaces. If I format code to “table”, use spaces.

FINAL QUESTIONS:

  1. Should there be the only one coding style in Ruby? I would prefer
    this,
    but…

  2. Do you think everyone would accept it? No, one group would accept
    TAB-style, another group would accept space-style. Maybe there could be
    two
    styles for each group.

  3. Would all people accept one of those two styles? I don’t think so.

  4. So should Ruby interpreter allow only those two styles? I don’t think
    so.

  5. Is there any solution for TABs vs. spaces? No, I don’t think so :wink:

  6. Is this “war” 50:50? Or is it finished? Or… Any ideas?

Thank you for any answer on questions above and/or solution for the
terminal
TAB length problem, which is the only real con of TABs for me.

Jan

2

Jan,

Of course, when I use TABs, I have to follow this
rule: Don’t use TABs elsewhere just before first
non-space character on a line.

This is the fatal flaw of using TABs.  There will inevitably be

cases where they get mixed, and as soon as that happens, the TABs are
required to be the length that that person chose, or the code does not
indent properly.

  1. Is there any solution for TABs vs. spaces?
Yes.  "unexpand -2" is your friend.  Just remember to "expand -2"

when you’re done.

I hope this helps.

- Warren B.
3

On 7/12/07, Jan Moliè [email protected] wrote:

FINAL QUESTIONS:

  1. Should there be the only one coding style in Ruby? I would prefer this,
    but…

Not coding style, indentation style. It’s not enforced, but you
pretty much should follow it if you have any interest in sharing code
with others.

  1. Do you think everyone would accept it? No, one group would accept
    TAB-style, another group would accept space-style. Maybe there could be two
    styles for each group.

Individual projects can decide their tabbing style. I’d find it
really annoying to work with projects that use hard tabs instead of
soft ones.

  1. Would all people accept one of those two styles? I don’t think so.

All people? Of course not. Most Rubyists prefer (or are willing to
accept) 2 space indentation.

  1. So should Ruby interpreter allow only those two styles? I don’t think so.

Huh? The ruby interpreter is whitespace agnostic. You’re thinking of
Python. Many of us dislike whitespace enforcement. :slight_smile:

  1. Is there any solution for TABs vs. spaces? No, I don’t think so :wink:

Sure. If you prefer tabs, just write a converter that substitutes
tabs to two spaces before sharing your code, configure it as a hotkey
in your editor if you’d like. This is one line of regex in pretty
much every place I can think of. (Something like: %s/\t/ /g works in
vim)

  1. Is this “war” 50:50? Or is it finished? Or… Any ideas?

Beyond finished. See most projects on RubyForge. Tabs are
considered evil in many languages, actually.

You mentioned that you don’t care how your code looks to your friends,
that’s the exact opposite of how I feel. It irks me that more than a
few people lately have totally missed the boat that minor
inconveniences for individuals can save a ton of hassle for the
community.

4

Hello, Jan,

Since you can’t see the difference, reinforcing use of only tabs when
using tabs is really hard - you sometimes miss a space.

That’s why I prefer spaces, and I think it’s the ruby community
attitude for the same reason. (My other reason is that I like ASCII to
be 100% content with no “markup” or “metadata”, and tabs are
metadata).

For those who must change the setting, their editors probably support
creating a macro that converts the files to tab on load and back to
spaces (with a 2sp setting) on save. It’s pretty easy in emacs.

For your commandlne problem, why don’t you create a script that
translates a tab into X spaces, call it some short name (like ‘tb’)
and pipe your code through it? So grep sort * | tb and you see what
you want.

Aur

5

Hi Jan Molič

I don’t think there’s really a solution to that problem as it is about
personal preferences. However, there are plenty of tools like
expand/unexpand to or even built into your editor to change code to your
liking.
That said, my preference is to use tabs for indention and space for
alignement. That way everybody can set the width of a tab as he likes it
and the code still looks fine.

Regards
Stefan

6

On Thu, Jul 12, 2007 at 11:34:55PM +0900, Jan Moli?? wrote:

I read somewhere that good-style Ruby code is indented by 2 spaces. I’d like
to tell you my problem: I’m not disabled, but I have problems with reading
code if the indentation is only at 2 spaces. I must indent more. It’s all
about my dysfunction of reading.

The main argument for using spaces is that the code looks everywhere same.
But - who needs it? From my point of view, I don’t care if the code looks
same on my and on my friend’s computer.

That’s the argument for using two spaces all the time rather than
sometimes using three or four spaces, and for choosing to stick with
just
spaces or just tabs rather than switching between the two. It’s not
specifically an argument for spaces over tabs.

There are arguments for spaces instead of tabs, but that’s not really
one
of them.

Of course, I expect the code to look same on my computer. There is a problem:
Unfortunately GNU/TAB is set to 8 characters and if you display code on
terminal, for example using diff or grep, it’s not well readable and may look
different than in your editor. So it breaks what I wrote above about
same-looking code within one computer. I don’t know if there is any solution
for this case or if TAB length is hardcoded in Linux/BSD kernel.

You can alter tab length in your editor (for at least most editors,
including vi/Vim and Emacs).

from Linux coding style:
“In short, 8-char indents make things easier to read, and have the added
benefit of warning you when you’re nesting your functions too deep.
Heed that warning.”

Using two spaces per indent also warns when functions are nested too
deeply. It requires twice as many keystrokes per indent as using tabs,
which means you’ll get tired of keystrokes for indentation twice as
quickly. It works as a reminder for me, anyway.

still look consistent on other’s computer even if different indentation is
used there. If you indent using spaces, you can’t set it alternatively (if
you don’t want to do recoding, which is bad idea).

There always be people who will need more indents because of their worse
recognition capability and they can do it thanks to TABs.

As mentioned in another response or two to your email, you can use the
expand and unexpand utilities to switch between spaces and tabs in your
source code files. I would recommend coding in tabs if you must, and
using the expand and unexpand utilities to change code formatting as
needed so that whenever you share code (such as on this list) you
present
it in two-space indentation style.

(Another con of TABs is editing code in editors which aren’t able to set
indenation (notepad). But. Do you usually use notepad for programming? (Hmm.
(…))

Parse error: mismatched parentheses.

  1. Do you think everyone would accept it? No, one group would accept
    TAB-style, another group would accept space-style. Maybe there could be two
    styles for each group.

  2. Would all people accept one of those two styles? I don’t think so.

  3. So should Ruby interpreter allow only those two styles? I don’t think so.

Last I checked, leading whitespace is not syntactically significant, and
I’d like to keep it that way. If I wanted significant whitespace, I’d
use Python.

  1. Is there any solution for TABs vs. spaces? No, I don’t think so :wink:

See above, re expand/unexpand.

  1. Is this “war” 50:50? Or is it finished? Or… Any ideas?

By far, the majority of programmers these days seem to prefer spaces
over
tabs. There are certain communities that run strongly the other way,
still, but I think they will continue to be increasingly outnumbered at
least until there’s a substantial shift in where things are headed in
that regard.

7

Of course, I expect the code to look same on my computer. There is a problem:
Unfortunately GNU/TAB is set to 8 characters and if you display code on
terminal, for example using diff or grep, it’s not well readable and may look
different than in your editor. So it breaks what I wrote above about
same-looking code within one computer. I don’t know if there is any solution
for this case or if TAB length is hardcoded in Linux/BSD kernel.

You can alter tab length in your editor (for at least most editors,
including vi/Vim and Emacs).

Not sure where all ‘expand’ is available, but at least on FreeBSD you
can
use it to convert tabs to N number of spaces… ala something like:

cat my_source_file.c | expand -4

http://www.freebsd.org/cgi/man.cgi?query=expand&apropos=0&sektion=0&manpath=FreeBSD+6.2-RELEASE&format=html

-philip

8

On 7/12/07, Chad P. [email protected] wrote:

Using two spaces per indent also warns when functions are nested too
deeply. It requires twice as many keystrokes per indent as using tabs,
which means you’ll get tired of keystrokes for indentation twice as
quickly. It works as a reminder for me, anyway.

I actually turn on expandtab, so that I can use the tab key still and
keep my spacebar from falling off. :slight_smile:

9

On Jul 12, 2007, at 4:52 PM, Gregory B. wrote:

Tabs/Spaces? is an age old debate as unimportant as where to put
opening/closing braces/brackets/parentheses in other languages.
This is less interesting than the god debate the other day.

10

On 7/12/07, John J. [email protected] wrote:

I actually turn on expandtab, so that I can use the tab key still and
keep my spacebar from falling off. :slight_smile:

Tabs/Spaces? is an age old debate as unimportant as where to put
opening/closing braces/brackets/parentheses in other languages.
This is less interesting than the god debate the other day.

Of course, it’s only important if you want to work on (almost) any
open source Ruby project.

11

On Jul 12, 8:48 am, “Warren B.” [email protected] wrote:

Jan,

Of course, when I use TABs, I have to follow this
rule: Don’t use TABs elsewhere just before first
non-space character on a line.

This is the fatal flaw of using TABs.  There will inevitably be

cases where they get mixed…

As anyone who’s ever read the Ruby source code can attest. :confused:

Death to tabs!

Regards,

Dan, who will always use 3-space, er, tabs.

12

On Thu, Jul 12, 2007 at 11:34:55PM +0900, Jan Moli?? wrote:

I read somewhere that good-style Ruby code is indented by 2 spaces. I’d like
to tell you my problem: I’m not disabled, but I have problems with reading
code if the indentation is only at 2 spaces. I must indent more. It’s all
about my dysfunction of reading.

I have similar vision issues. It takes me a while to parse two space
indentation in passages where the indentation isn’t obvious from
context.
Four spaces isn’t so bad, and I can fly through eight spaces.

The main argument for using spaces is that the code looks everywhere same.
But - who needs it? From my point of view, I don’t care if the code looks
same on my and on my friend’s computer.

Sometimes I prefer for code not to look the same. If I’m on a terminal
with larger text area but a smaller font, I need larger indentation but
have the column space to sacrifice. If I’m on an 80 column terminal,
eight
space indentation results in line wraps, and since the font is bigger I
have less trouble parsing 2-4 space tabs.

FINAL QUESTIONS:

  1. Should there be the only one coding style in Ruby? I would prefer this,
    but…

It’s best to have a consistent coding style across a single project.
With
free software, it also helps to have a consistent coding style across a
language since folks inevitably cherry pick code from multiple projects.

That said, I don’t think you’re going to see excessive complaints over
hard tabbed code as compared to other coding style deviations.

  1. Do you think everyone would accept it? No, one group would accept
    TAB-style, another group would accept space-style. Maybe there could be two
    styles for each group.

The real problem isn’t whether folks would accept it, but rather would
folks acknowledge it.

Don’t get me wrong, I’m with you here. In my own code I prefer to use
hard
tabs. However, I rarely advocate their use outside of my own code these
days.

The problem, as others have mentioned, is that using hard tabs properly
requires a certain dedication to consistency. Most people don’t have
that
discipline and will add spaces willy-nilly to make things look right on
their screen. The end result is a tab/space combination that’s broken
for
everyone. That’s worse than the alternative of spaces only.

  1. Is there any solution for TABs vs. spaces? No, I don’t think so :wink:

Yes, sadly it’s spaces. Although I’d love for the world to accept tabs
and
use them properly, the only way to avoid the problems that will
inevitably
result is to go space only.