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

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