Indentation vs. "end"s

[Thomas Kirchner]

For what it's worth, I also strongly dislike it. It was one of my
least favorite features of OCaml's syntax.

But here, the biggest problem is that (relative to other block endings
in pretty much any language I can think of), it's much harder to
visually count ;;s if they are squashed together as in your example.

I think this is largely because there aren't any visual cues to the
boundary between tokens. The gap between two ;s within the same ;; and
the gap between two ;s in adjacent ;; aren't visually distinguishable.

I was going to write my own post, but it seems MenTaLguY did it for me!

I am in total agreement; semicolons are an ugly way to end sections.
Curly braces I have a much easier time with.

Tom

 

[Mark Volkmann]

I was going to write my own post, but it seems MenTaLguY did it for me!

I am in total agreement; semicolons are an ugly way to end sections.
Curly braces I have a much easier time with.

I'm not a fan of the curly braces, but if we do end up using them, I
hope we don't allow this.

def some_method(args)
# some code
}

If we're going to use them, I think they need to be matched, so a {
should appear at the end of the method argument list.

 

[Thomas Kirchner]

I'm not a fan of the curly braces, but if we do end up using them, I
hope we don't allow this.

def some_method(args)
# some code
}

If we're going to use them, I think they need to be matched, so a {
should appear at the end of the method argument list.

Oh, I definitely agree here - I should have clarified. I enjoy _matched_
curly braces In most cases, I prefer curly braces for blocks rather
than "do ... end".

However, I don't think they're necessary here - "def method() ... end"
works well and looks good. It's balanced.

Tom

 

[Dirk Meijer]

------=_Part_6236_22912487.1138977335820
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

hi,

if we do end up using them

in this discussion, a sentence with the words 'do' and 'end' is hard to rea=
d
properly
but seriously..

If we're going to use them, I think they need to be matched, so a {

should appear at the end of the method argument list.

i think this is a bad idea, i really prefer keywords over punctuation,
because it's easy to find a spelling error in a keyword (especially if your
editor highlights them) but i often find i used one brace and one bracket,
which is easily overlooked and easily done, as the button are close to
eachother on the keyboard.
and it looks too much like Java to me

greetings, Dirk

------=_Part_6236_22912487.1138977335820--

 

[Sky Yin]

Even if "end if" is no longer feasible to parse because of the if
modifier there is still the possibility to have optional "end def" and
"end class" instead of just "end". It could make finding the place
where an end is missing much easier.

Michal

(0..10).each do |i|
# Do something with i
end what?

I agree with you mostly on this kind of option, since I always add
comments after every 'end' of a deep embedded structure to make the
logic more readable.

 

[Doug H]

(0..10).each do |i|
# Do something with i
end what?

end do

 

[Thomas Kirchner]

end do

My first reaction was "end each"... After all, "do" and "end" are just
the keywords. "end <something>" should refer to the actual construct
you're ending, not just a keyword.

Either way, I think it's ugly

Tom

 

[Michael Sullivan]

 

[Sky Yin]

I may take back the previous agreement on the "end option". Since
there's a space between "end" and the "option" (otherwise we have to
introduce tons of new key words), it's hard to parse. For example, how
can the interpreter know the "while" in "end while" is not a key word
to begin a while loop? For the iteration example I asked, the actually
comment I put in code is:

(0..10).each do |i|
# Do something with i
end # Next i

More readable?

 

[Doug H]

My first reaction was "end each"... After all, "do" and "end" are just
the keywords. "end <something>" should refer to the actual construct
you're ending, not just a keyword.

You're ending a closure block, which starts with "do".

 

[Wilson Bilkovich]

end do

I've always just done this:

def blah(var)
if something
case var
when 'x'
foo
when 'y'
bar
end#case
end#if
end#blah

 

[Dirk Meijer]

------=_Part_14290_5032149.1139008614821
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I've always just done this:

def blah(var)
if something
case var
when 'x'
foo
when 'y'
bar
end#case
end#if
end#blah

best solution i've seen so far! *sticks thumb up* i think i'll start using
that too

------=_Part_14290_5032149.1139008614821--

 

[Luke Duncalfe]

Hi,

I'm not the most experienced Ruby user, but for what it's worth one of the
reasons I chose to program in Ruby is because the language looked, to me, so
damn nice. I'm an artist who works as a programmer, so flaky reasons like
the aesthetics of the code were very important to me in deciding to take
Ruby on.

I don't really like the idea of ;; because to me it breaks the beauty of
Ruby code. But I do like the idea of have symbols replace an 'end'. My take
on a nicer symbol to use would be '<', it's like pointing back to the margin
saying 'go home now'. Except, any multiple symbol would, I think, not really
help to clarify the code, and would instead just be quicker to type than
'end'. How about having one symbol, which basically would end all nested
functions and conditionals, except not close the class.

So working with Matz's example, it would look like this:

class Foo
def bar(a)
p a
<
end

Or, with more nesting

class Foo
def bar(a)
if (a)
p a
<
end

So, without a class, code could look like this:

if (a)
if (b)
if (c)
if (d)
p e
<


?

Luke

Hi,

In message "Re: Indentation vs. "end"s"

 

[gabriele renzi]

Austin Ziegler ha scritto:

I hope that the mistake that Python makes isn't repeated in Ruby 2.0.

I prefer explicit -- and more flexible -- than implicit and
inflexible.

are you citing line 2 of "the zen of python"[1] consciously?

In other words, I really *do* like the ends.

I always have the feeling that there could be something better than
ends, but untile I find it I'm happy with them.



[1] http://www.python.org/doc/Humor.html#zen

 

[Eustaquio Rangel de Oliveira J]

In other words, I really *do* like the ends.

Me too. I always say that the Ruby all control
structures always ends on the end. It's easier and
simpler. If-(endif-fi-etc) makes some confusion when
you work with a couple of languages. Ends are cool.


And, talking about indentation, with we work with tab
we'll have another dilema: tabs or spaces, as Python.=20

Check http://www.python.org/doc/essays/styleguide.html.

 

[Sung Soo Kim]

------=_Part_22210_18361051.1139093801748
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline



I really like "end" IF there is an autocomplete feature in the editor. If
not, well... But the main point is that, it makes the code clearer, and
that's why I like it. (again if the editor autocompletes 'end' for me )

------=_Part_22210_18361051.1139093801748--

 

[David Vallner]

D=C5=88a Sobota 04 Febru=C3=A1r 2006 10:53 gabriele renzi nap=C3=ADsal:

Austin Ziegler ha scritto:

are you citing line 2 of "the zen of python" consciously?

The irony is UNBEARABLE, I tell ya...

To make this less complete spam, I state I don't like curly braces. I blame=
=20
the horrors of learning C at college, the horrors of coding JavaScript at=20
school, and this godawful cheapo plastic taiwanese keyboard with a German=20
layout that makes typing them a horrible pinky-strain.=20

That said, I can somehow understand, if not actively appreciate Ruby having=
=20
optional C-like features for the sake of C-likeness. The forces of marketin=
g=20
in the programming language market are brutal and unyielding, the fact peop=
le=20
are willing to accept, nay, like C# with its deluge of keywords, half of=20
which mostly serve for the compiler only to slap you for not using them whe=
n=20
appropriate. (Why the hell can't I use ``this'' to reference static members=
=20
in a static context?! *bangs head against wall*)

David Vallner
Slashdot score me and have your goldfish die

 

[David Vallner]

Intriguing idea, but completely ad-hoc, and potentially confusing and=20
unreadable. Especially if someone were to apply it with the "Few small=20
classes per method" style of programming, or any similar meta contexts. Wha=
t=20
exactly would the ``<'' close then? The innermost or the outermost class?=20
What about a module used as a namespace containing several spaces classes i=
n=20
a single source file?=20

A magic "end almost everything for given values of almost everything" would=
be=20
just repeating the constant lookup issue all over again. Not necessarily a=
=20
problem to bite you in the majority of cases, but another bit of syntax mos=
t=20
people can't really remember how it really works.

I might also be horribly, horribly wrong. In that case, ignore me as usual.

David Vallner

D=C5=88a Sobota 04 Febru=C3=A1r 2006 08:13 Luke Duncalfe nap=C3=ADsal:

 

[joesb]

Yes I really like the end statements, and they make it easier for
beginners. It's possible to support both indenting and end statements
(i.e. support one mode or the other), and you don't need python's
redundant and unnecessary colons. I implemented this myself in a
parser. I don't think it is appropriate for ruby, however.

What would be even better would be to allow optional labels after end
statements, such as "end class", "end def", so the parser can catch
more errors.
I've implemented this as well in a separate project.

Instead of voting for multiple "end xxx", I would like to suggest that
more pairs/keyword than "do ... end" and "{ .. }" can be used to define
a block.

For examples:

begin ... end
is ... end
then ... end

Because sometimes, the correct word is not "do". For examples to define
mapping I'd like to do

Brain.learn :cooking is
...
end

rather having "do" there.
It also simplify many semantic in Ruby for example. defining
class/method could be viewed as a method that takes a block. But "do"
wouldn't make sense there, but:

class Person is #<<< just a method taking a block
def say(message) is #<<< Don't know :S
...
end
end

It may make Ruby code reflect more closely to what I am thinking in
word.

 

[tony summerfelt]

Yukihiro Matsumoto wrote on 2/2/2006 9:12 PM:

class Foo
def bar(a)
p a
;;
;;

ooh, i like that.

p a;;;;

speaking for myself, i wouldn't write code like that. but i do like
the semi colon idea