Previous
Prev
Contents
Contents
Next
Next
 Ruby user's guide Nuts and bolts  

This chapter addresses a few practical issues.


Statement delimiters

Some languages require some kind of punctuation, often a semicolon (;), to end each statement in a program.  Ruby instead follows the convention used in shells like sh and csh.  Multiple statements on one line must be separated by semicolons, but they are not required at the end of a line; a linefeed is treated like a semicolon.  If a line ends with a backslash (\), the linefeed following it is ignored; this allows you to have a single logical line that spans several lines.


Comments

Ruby follows a common scripting convention, which is to use a pound sign (#) to denote the start of a comment.  Anything following an unquoted #, to the end of the line on which it appears, is ignored by the interpreter.  Writing comments into code is a very good practice, and one that is neglected by too many programmers.  Although well written code tends to be self-documenting, it never hurts to scribble in the margins, and it's almost always a mistake to believe that others will be able to look at your code and immediately see it the way you do.  (For practical purposes, you yourself are "another person" within a few days anyway - which of us hasn't gone back to fix or enhance a program after the passage of time and said, I know I wrote this, but what in blazes does it mean?  Make it easy on yourself; keep some notes.)

To facilitate large comment blocks, the ruby interpreter also ignores anything between a line starting with "=begin" and another line starting with "=end".

#!/usr/local/bin/ruby

=begin
**********************************************************************
  This is a comment block, something you write for the benefit of
  human readers (including yourself).  The interpreter ignores it.
  There is no need for a '#' at the start of every line.
**********************************************************************
=end

print "Hello, world.\n"

Forward references

The ruby interpreter processes code as it reads it.  There is nothing like a compilation phase; if something hasn't been read yet, it is simply undefined.

# this results in an "undefined method" error:

print successor(3),"\n"

def successor(x)
  x + 1
end

However, this does not force you to organize your code in a strictly "bottom-up" fashion.  When the interpreter encounters a method definition, it can safely include undefined references, as long as you can be sure they will be defined by the time the method is actually invoked:

# Conversion of fahrenheit to celsius, broken
# down into two steps.

def f_to_c(f)
  scale (f - 32.0)  # This is a forward reference, but it's okay.
end

def scale(x)
  x * 5.0 / 9.0
end

printf "%.1f is a comfortable temperature.\n", f_to_c( 72.3 )

So while this may seem less convenient than what you may be used to in Perl or Java, it is less restrictive than trying to write C without prototypes (which would require you to always maintain a partial ordering of what references what).  Putting top-level code at the bottom of a source file always works.  And even this is less of an annoyance than it might at first seem.  You already know that very long and complicated source files are undesirable in any language; ruby provides load and require, allowing you to break code up into clear, readable, and logically related chunks.  A nice consequence of this is that your program can execute from near the top of a file while avoiding any problems with forward references.

load 'f_to_c.rb'

printf "%.1f is a bit warm for me.\n", f_to_c( 117 )
# f_to_c.rb

# This file can be arranged in any way you like, since the interpreter
# will read all of it before the main program needs any of it.

def f_to_c(f)
  ... 
end

Yet to be written...

There are several topics that are not yet addressed in this tutorial, including:

But by now you may be ready to dig into the reference manual to learn about ruby in more depth.  The FAQ and Library reference are also important resources.

Good luck, and happy coding!


Previous
Prev
Contents
Contents
Next
Next