Why not adopt "Python Style" indentation for Ruby?

[Marc Heiler]

"tabs can be made forbidden (g.v.rossum himself said he'd never
supported tabs in the first place if he new what it would cauze)"

Just a bit offtopic: I personally used tabs a lot and told people
that they could adjust them to their space-likings (2 or 4), however
as I comment quite a lot, i did find myself mixing tabs and spaces
so I finally changed, avoid using tabs, and use 2 spaces now
everywhere for code. (2 spaces because i like to keep 80 chars /
line, so i can fit more into a line )

 

[Chad Perrin]

Let's try:

describe 'myself'
it 'should be readable'
lambda
@reader.reading
.should change
@reader.knowledge
.by(text.amount)

If Ruby looked like that, I'd probably not have bothered -- just stuck
with Perl.

 

[Trans]

Let's try:

describe 'myself'
it 'should be readable'
lambda
@reader.reading
.should change
@reader.knowledge
.by(text.amount)

# pretty much impossible, if you ask me
# same in usual ruby now

describe 'myself' do
it 'should be readable'
lambda{ @reader.reading }.
should change{ @reader.knowledge }.
by(text.amount)
end
end

(I take it you meant 'if' not 'it')

# well?

Actually, the later is pretty dang ugly --maybe worse the the first.
However colons would help the first example quite a bit:

describe 'myself':
if 'should be readable':
lambda:
@reader.reading
.should change:
@reader.knowledge
.by(text.amount)

Though any such indention significance is probably too big of a change
for Ruby at this point anyway. I'd much rather just see more
intelligent was to catch missing "end" errors. Even if meant the
option to put "endif", "endclass", etc.

T.


T.

 

[Chad Perrin]

Actually, the later is pretty dang ugly --maybe worse the the first.
However colons would help the first example quite a bit:

describe 'myself':
if 'should be readable':
lambda:
@reader.reading
.should change:
@reader.knowledge
.by(text.amount)

Though any such indention significance is probably too big of a change
for Ruby at this point anyway. I'd much rather just see more
intelligent was to catch missing "end" errors. Even if meant the
option to put "endif", "endclass", etc.

I'd prefer we keep the plain ol' "end" syntax, and use editors that can
do delimiter matching as easily with "end" as with braces, brackets, or
parentheses.

 

[Trans]

I'd prefer we keep the plain ol' "end" syntax, and use editors that can
do delimiter matching as easily with "end" as with braces, brackets, or
parentheses.

Yes, that would be nice, but I've yet to see an editor do it.

T.

 

[Stian Haklev]

I agree that I would like the end statements to become more specific -
at least optionally... I hate when you have a long class file and you
get the dreaded Unexpected end of file, expecting END or something...
and you have no idea where in the 200 lines you forgot to insert an end,
or you left a brace hanging on the line above an end or what not. Even
if we didn't mandate endif, we could let end do what it does, but with
an optional argument (end if, end class, end def) - I would use these,
and the interpreter would thus be able to catch the error a lot closer
to the source -- class not closed at line 50 is more helpful then end of
file at line 230...

Stian

 

[gga]

Vim does this just fine.

Really? Not the vim I'm using (cream). It matches parentheses/
brackets like most editors, but it does nothing to hilight matching do/
end or def/end blocks. Its status line also tells me nothing about
what function or class I'm in either. Worse, if I close a bracket,
and the opening of it is outside the "page", it does not tell me what
the opening statement was. So... no, I'd say it definitively fails
and is worse than emacs.
Or perhaps there's a setting I missed?

 

[Gregory Brown]

Really? Not the vim I'm using (cream). It matches parentheses/
brackets like most editors, but it does nothing to hilight matching do/
end or def/end blocks. Its status line also tells me nothing about
what function or class I'm in either. Worse, if I close a bracket,
and the opening of it is outside the "page", it does not tell me what
the opening statement was. So... no, I'd say it definitively fails
and is worse than emacs.
Or perhaps there's a setting I missed?

It's probably that Cream does not have the proper ruby configuration
files bundled with it.
Consider using plain vim or gvim rather than Cream, as it gets rid of
most of the reasons you'd use vim!

 

[bbiker]

It's probably that Cream does not have the proper ruby configuration
files bundled with it.
Consider using plain vim or gvim rather than Cream, as it gets rid of
most of the reasons you'd use vim!

Someone wrote a macro (or whatever it is called) for gvim that
automatically inserts an "end" statement whenever you enter a keyword
that requires an "end".

for example:
type:

"if cond" and press return

the cursor goes to the next line and an "end" statement appears on the
subsequent line with the proper indentation.

if cond
# cursor at start of this line.
end

 

[Austin Ziegler]

Really? Not the vim I'm using (cream). It matches parentheses/
brackets like most editors, but it does nothing to hilight matching do/
end or def/end blocks. Its status line also tells me nothing about
what function or class I'm in either. Worse, if I close a bracket,
and the opening of it is outside the "page", it does not tell me what
the opening statement was. So... no, I'd say it definitively fails
and is worse than emacs.

Or perhaps there's a setting I missed?

I don't use the cream settings. I use vim with the Ruby settings
available on RubyForge. Now, automatic highlighting isn't present
(e.g., the same way you get with {}), but you *can* hit "%" to jump
between matching pairs. It isn't for everyone, either, but the folding
available with vim does more for me being certain of matched pairs
than anything else (if it doesn't fold properly, it isn't likely to
compile properly).

I have TextMate (but don't use it), and I'm pretty sure it can do the
same. I've heard good things about Kate from Linux users, too.

-austin

 

[Benjamin Kudria]

I have TextMate (but don't use it), and I'm pretty sure it can do the
same. I've heard good things about Kate from Linux users, too.

Indeed, Kate is great (although not as good as what I'veseen/heard about
Textmate) butit certainly doesn't highlight do...end combinations, only the
standard [], {}, etc. It may be possible to add support for it, however.

-Ben

 

[Erik Hollensbe]

Really? Not the vim I'm using (cream). It matches parentheses/
brackets like most editors, but it does nothing to hilight matching do/
end or def/end blocks. Its status line also tells me nothing about
what function or class I'm in either. Worse, if I close a bracket,
and the opening of it is outside the "page", it does not tell me what
the opening statement was. So... no, I'd say it definitively fails
and is worse than emacs.
Or perhaps there's a setting I missed?

% works, but I'm using a ruby-matchit plugin I found on vim.org. I'm
not sure if this is the same as the dist that a few guys have been
working on at rubyforge.

 

[Rick DeNatale]

On 2007-05-20 20:45:59 -0700, gga <[email protected]> said:

% works, but I'm using a ruby-matchit plugin I found on vim.org. I'm
not sure if this is the same as the dist that a few guys have been
working on at rubyforge.

% in vim does something related to what he's asking for, but it
doesn't automatically highlight the matching token when the cursor
lands on it's mate. G?Vim will do this for single character matching
tokens like ( ), [] and {}, as you move the cursor over one of these
it will highlight its mate if it doesn't have to scroll to do so.

Personally, I don't miss it much.

 

[Keith Fahlgren]

% works, but I'm using a ruby-matchit plugin I found on vim.org. I'm
not sure if this is the same as the dist that a few guys have been
working on at rubyforge.

% in vim does something related to what he's asking for, but it
doesn't automatically highlight the matching token when the cursor
lands on it's mate. G?Vim will do this for single character matching
tokens like ( ), [] and {}, as you move the cursor over one of these
it will highlight its mate if it doesn't have to scroll to do so.

Actually, mate-highlighting was added in vim 7:
http://vimdoc.sourceforge.net/htmldoc/pi_paren.html#matchparen


HTH,
Keith

 

[Rick DeNatale]

% works, but I'm using a ruby-matchit plugin I found on vim.org. I'm
not sure if this is the same as the dist that a few guys have been
working on at rubyforge.

% in vim does something related to what he's asking for, but it
doesn't automatically highlight the matching token when the cursor
lands on it's mate. G?Vim will do this for single character matching
tokens like ( ), [] and {}, as you move the cursor over one of these
it will highlight its mate if it doesn't have to scroll to do so.

Actually, mate-highlighting was added in vim 7:
http://vimdoc.sourceforge.net/htmldoc/pi_paren.html#matchparen

Right, which is what I use. And as I said, it only highlights pairs
of single character delimiters which are unequal, it can't highlight
do/end or "/".

 

[Jerry Blanco]

If you install the Vim/Ruby (http://vim-ruby.rubyforge.org/) plugins
it'll work with % and do/end.

Also, if you

:set sm

it will highlight briefly the opening of a block by the cursor going
there and back really quickly AND setting the opening and closing
markers in a different color.

There are some options with sm (showmatch) that I don't recall. Do

:help showmatch

in Vim for details.

My experience with Vim is that if you can think of ANYTHING for Vim to
do, chances are someone thought of it and created a plugin for it
(yes, you can play tetris and sokoban with vim ->
(http://www.vim.org/scripts/script_s..._by=rating&direction=descending&search=search).

If you haven't, I'd suggest checking the scripts section in vim.org
(http://www.vim.org/scripts/index.php). Also, use the search
(http://www.vim.org/search.php) to look for plugins.

HTH

Jerry.

% works, but I'm using a ruby-matchit plugin I found on vim.org. I'm
not sure if this is the same as the dist that a few guys have been
working on at rubyforge.

% in vim does something related to what he's asking for, but it
doesn't automatically highlight the matching token when the cursor
lands on it's mate. G?Vim will do this for single character matching
tokens like ( ), [] and {}, as you move the cursor over one of these
it will highlight its mate if it doesn't have to scroll to do so.

Actually, mate-highlighting was added in vim 7:
http://vimdoc.sourceforge.net/htmldoc/pi_paren.html#matchparen

Right, which is what I use. And as I said, it only highlights pairs
of single character delimiters which are unequal, it can't highlight
do/end or "/".

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

 

[Jinjing Wang]

I love indentations too..

Check out my project for Ruby space convention :/

http://lazibi.rubyforge.org

It's code generation.

 

[Brad Phelan]

I love indentations too..

Check out my project for Ruby space convention :/

http://lazibi.rubyforge.org

It's code generation.

You don't need to do code generation, at least in the way you have done
it. I posted a solution way back up this thread that does not require
the creation of intermediate files to load.

In foo.rb

require 'pyrb.rb'
__END__

def foo:
[1,2,3,4].each do |i|:
puts i
[1,2,3,4].each do |j|:
puts i
if i == 2 :
puts "foo"
else:
puts "bar"


foo


See

http://xtargets.com/snippets/posts/show/68

for the details.

 

[Frasier Mruby]

Dear Mats,

I am kind of new to ruby and like it after looking python first. As
some other people said, my only major complaint is it's many "END".
Among java/c/C++/python, the "END" keep reminding me the inconvenience
of it during coding ruby. I like ruby because it's easy to learn, and
to read. It's designed for be friends of programmers. But I feel the
"END" may have a negative role to ruby's purpose or attraction.

I am fine to have "END" for class or methods. But for IF,WHILE, CASE,
FOR, etc., when there are many levels it often make me confused what the
matching part of the those "END"s are.

I understand and agree your comment that ruby had better to have
something to close the code block. But I sincerely hope you could come
up something else to replace the "END".

My first thought to use brace "{...}" to replace "END" since it's a
popular convention.

I suggest to use only the "do...end" to formalize the blocks, brace {}
will be stopped to be used. It seems to me it's a waste of symbols to
have two ways to represent blocks, which may not be the most frequently
used. Or consider to use use:
"/* */", "|...|", "<...>", "[...]" , "(...)", "((...))", , "//...//", "
:...: ", " '...' ", " `...` " for blocks.

To enhance readability is probably one of ruby's design purpose and I
really hope some thing could be done earlier to make the "END" looks
prettier.

Thank you!

* tab/space mixture
* templates, e.g. eRuby
* expression with code chunk, e.g lambdas and blocks

* clipboards, email, pastebins, and other places where the code is not
preserved literally

 

[James Britt]

Frasier Mruby wrote:

Why not adopt "Python Style" indentation for Ruby? Because that would
bite a big one.

I am fine to have "END" for class or methods. But for IF,WHILE, CASE,
FOR, etc., when there are many levels it often make me confused what the
matching part of the those "END"s are.

Then don't do that. Seriously. Twisty conditionals is a code smell.
(Having fought with deep hierarchies of YAML and HAML, the lack of an
explicit "end" token doesn't really help in complex documents; in fact,
it can be detriment. Sometimes explicit is better than implicit.)


BTW, doesn't your code editor find the matching braces (or do/ends) for
you? (If not, get a real editor. They're free.)

To enhance readability is probably one of ruby's design purpose and I
really hope some thing could be done earlier to make the "END" looks
prettier.

I *rarely* run into Ruby code that is not readable. When I do, it's
almost always for a reason (e.g. Camping source code, or some code
golfing).

The idea that coders need to be coerced into writing readable code is as
flawed as that of the need for Java-style static typing to avoid bugs.

It sounds good in blog posts and mailing lists, but lacks empirical
evidence.


--
James Britt

www.happycamperstudios.com - Wicked Cool Coding
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff