Beginners question: branching and ends

ruby-talk
1

trying to figure out exactly where 'end' needs to be in my code. I'm
using Scite and find that often time it will report 'expecting kEND'
at the last line of the code and not where the kEND should actually
be. It would be nice if there was more accuracy but I won't expect
it.

so if this is my code

somearray.each do |x|
    anotherarray.each do |y|
       if x == y
            ......do something.......
              else
                     .....do something..........
        end # I have this 'end' for the if/else statement
     end # this 'end' is for the somearray loop
  end # and this is the one question, but I'm guessing (i know not
good to guess) that this # one is needed for the
anotherarray loop ?

Would this be correct ? One thing I've found is that having the right
number of ends will make the code execute but having them in the wrong
place will have surprising results.

TIA
Stuart

2

trying to figure out exactly where 'end' needs to be in my code. I'm
using Scite and find that often time it will report 'expecting kEND'
at the last line of the code and not where the kEND should actually
be. It would be nice if there was more accuracy but I won't expect
it.

so if this is my code

somearray.each do |x|
    anotherarray.each do |y|
       if x == y
            ......do something.......
              else
                     .....do something..........
        end # I have this 'end' for the if/else statement
     end # this 'end' is for the somearray loop
  end # and this is the one question, but I'm guessing (i know not
good to guess) that this # one is needed for the
anotherarray loop ?

Would this be correct ? One thing I've found is that having the right
number of ends will make the code execute but having them in the wrong
place will have surprising results.

*nods* Looks just fine to me.

3

Stuart;

I've taken the liberty of reformating your code here. It is really
important you you indent things correctly so that you can see the
structure of the code clearly. You'll see that I've added lines to in
the columns showing each construct and it's matching end tag:

somearray.each do |x|

anotherarray.each do |y|
> if x == y
> > # ......do something.......
> else
> > # .....do something..........
> end
end

end

See? As you suspected, the first end is paired up with the if/else
construct. As indented above; however, you can plainly see how the
end keywords match up with their controlling constructs. It turns out
that you had the meaning of the last two ends switched in your
comments.

Everything needs to be properly nested. That is, you need to end the
first do block before you can end the enclosed one.

I hope that helps a little.

···

--
Lou.

4

trying to figure out exactly where 'end' needs to be in my code. I'm
using Scite and find that often time it will report 'expecting kEND'
at the last line of the code and not where the kEND should actually
be. It would be nice if there was more accuracy but I won't expect
it.

You shouldn't expect it - it's a hard thing to catch that sort of error in a compiler or interpreter. Think of it this way:

begin
   begin
     begin
       begin
       # end <- oops!
     end
   end
end

The mistake is the 'end' commented out, but to the interpreter, the only missing one is at the very end, since the three 'end's that exist match the first three 'begin's. Because Ruby's very liberal when it comes to what statements you can make and where (e.g., nested methods), it might not be clear there's an 'end' missing until the end of the file, and even then, there's no simple way to tell which 'end' is actually missing, just that one is.

so if this is my code

somearray.each do |x|
   anotherarray.each do |y|
      if x == y
           ......do something.......
             else
                    .....do something..........
       end # I have this 'end' for the if/else statement
    end # this 'end' is for the somearray loop
end # and this is the one question, but I'm guessing (i know not
good to guess) that this # one is needed for the
anotherarray loop ?

Would this be correct ? One thing I've found is that having the right
number of ends will make the code execute but having them in the wrong
place will have surprising results.

That's not correct: the first end corresponds to the 'if/else', but you have the other ones mixed up: the second end corresponds to anotherarray.each, and the third one corresponds to somearray.each. Think of it like nested boxes or Russian dolls: each begin/end block is contained inside an outer one:

begin # 1
   begin # 2
     begin # 3
     end # 3
   end # 2
end # 1

As an interesting note, this is one of the ways in which keeping your code indented properly makes things easier for you in the long run - you can actually see which 'end' aligns to which 'begin'. The major benefit of proper indentation is that it makes life easier for people on the mailing list who have to read your code.

matthew smillie.

···

On Jun 28, 2006, at 13:01, Dark Ambient wrote:

5

Helps a great deal! TY. I do use indentation and the odd thing is when
I cut/paste into the email , the indentation remains intact. I'm not
sure what gmail is doing (if anything) once it gets sent.

Stuart

···

On 6/28/06, Louis J Scoras <louis.j.scoras@gmail.com> wrote:

Stuart;

I've taken the liberty of reformating your code here. It is really
important you you indent things correctly so that you can see the
structure of the code clearly. You'll see that I've added lines to in
the columns showing each construct and it's matching end tag:

somearray.each do |x|
> anotherarray.each do |y|
> > if x == y
> > > # ......do something.......
> > else
> > > # .....do something..........
> > end
> end
end

See? As you suspected, the first end is paired up with the if/else
construct. As indented above; however, you can plainly see how the
end keywords match up with their controlling constructs. It turns out
that you had the meaning of the last two ends switched in your
comments.

Everything needs to be properly nested. That is, you need to end the
first do block before you can end the enclosed one.

I hope that helps a little.

--
Lou.

6

Just adding to that: every IDE will have a hard time figuring out
*where* exactly you missed an end. That's next to impossible. For
example

foo.each do |x|
  x.each do |a|
    puts a
  end # assume this was missing
  puts x.size
end

No ide could guess whether the "end" was missing in the marked line or
in the line after "puts x.size" (which could be any other statement or
sequence of statements).

That's why Ruby usually complains at the end of the file. A good way
to prevent this is to create the habit of entering all pairs
(brackets, if then end, do end etc.) immediately before entering the
code between them. Or use an IDE that does it for you.

Kind regards

robert

···

2006/6/28, Louis J Scoras <louis.j.scoras@gmail.com>:

Everything needs to be properly nested. That is, you need to end the
first do block before you can end the enclosed one.

--
Have a look: Robert K. | Flickr

7

I've found that GMail often mucks up code for whatever reason. You should
check out nopaste[1] or pastebin[2].

[1]: <http://rafb.net/paste/&gt;
[2]: <http://pastebin.com/&gt;

···

Dean

On 6/28/06, Dark Ambient <sambient@gmail.com> wrote:

Helps a great deal! TY. I do use indentation and the odd thing is when
I cut/paste into the email , the indentation remains intact. I'm not
sure what gmail is doing (if anything) once it gets sent.

Stuart

On 6/28/06, Louis J Scoras <louis.j.scoras@gmail.com> wrote:
> Stuart;
>
> I've taken the liberty of reformating your code here. It is really
> important you you indent things correctly so that you can see the
> structure of the code clearly. You'll see that I've added lines to in
> the columns showing each construct and it's matching end tag:
>
> somearray.each do |x|
> > anotherarray.each do |y|
> > > if x == y
> > > > # ......do something.......
> > > else
> > > > # .....do something..........
> > > end
> > end
> end
>
> See? As you suspected, the first end is paired up with the if/else
> construct. As indented above; however, you can plainly see how the
> end keywords match up with their controlling constructs. It turns out
> that you had the meaning of the last two ends switched in your
> comments.
>
> Everything needs to be properly nested. That is, you need to end the
> first do block before you can end the enclosed one.
>
> I hope that helps a little.
>
> --
> Lou.
>

8

Ahh, yes. I assumed that the indenting in the message was correct
because there was *some* indenting in there. Weird that gmail would
mess that up. Are you posting using plain text or 'rich formatting'?

···

On 6/28/06, Dark Ambient <sambient@gmail.com> wrote:

Helps a great deal! TY. I do use indentation and the odd thing is when
I cut/paste into the email , the indentation remains intact. I'm not
sure what gmail is doing (if anything) once it gets sent.

--
Lou.

9

Sorry to deviate from the original question, but I'd like to say that whether
gmail messes up indenting or not, it's better to put code in your mailing
list email because 1) people don't have to open their browser to see what
you're talking about and 2) If someone is looking through the archives, they
can still read your code (paste bin sites normally expire pastes after
24-72hours).

Alex

···

On Wednesday 28 June 2006 18:52, Dean Strelau wrote:

I've found that GMail often mucks up code for whatever reason. You should
check out nopaste[1] or pastebin[2].

10

Plain text

···

On 6/28/06, Louis J Scoras <louis.j.scoras@gmail.com> wrote:

On 6/28/06, Dark Ambient <sambient@gmail.com> wrote:
> Helps a great deal! TY. I do use indentation and the odd thing is when
> I cut/paste into the email , the indentation remains intact. I'm not
> sure what gmail is doing (if anything) once it gets sent.

Ahh, yes. I assumed that the indenting in the message was correct
because there was *some* indenting in there. Weird that gmail would
mess that up. Are you posting using plain text or 'rich formatting'?

--
Lou.

11

Sorry to deviate from the original question, but I'd like to say that
whether

gmail messes up indenting or not, it's better to put code in your mailing

list email because 1) people don't have to open their browser to see what
you're talking about and 2) If someone is looking through the archives,
they
can still read your code (paste bin sites normally expire pastes after
24-72hours).

This is a valid point, but I've given up on threads because the code gets
mangled. I guess maybe the ultimate answer here is put your code in the
message, and if you're nice, pastebin it too.

[/tangent]

···

Dean