A Job With a Name

As a program grows, the same little job turns up again and again: draw the border, show the score, play the sound. Copy it into every place that needs it and two things go wrong. The program bloats, and the day you want to change that job you have to find every copy.

Better to package the job up, write it once, and call on it wherever you need it.

Write it once, call it

DEFINE divider
  SHOW "----------"
END

CALL divider
SHOW "Top news"

----------
Top news

DEFINE gives a job a name and holds the work under it. CALL runs that job. When the job finishes, the program carries on from the line after the CALL.

The order the lines run in is not the order you read them, which is the part a listing cannot show you:

The name is the point. divider says what the block is for, so you can read CALL divider without going to look at what it does.

The point is reuse

You can call one job as many times as you like, and that is where writing it once earns its keep:

DEFINE divider
  SHOW "----------"
END

CALL divider
SHOW "Top news"
CALL divider
SHOW "More news"
CALL divider

----------
Top news
----------
More news
----------

The divider appears three times on screen and exists once in the program. That is the whole value: say it once. Want stars instead of dashes? Change the one line inside divider, and all three follow.

As programs grow into real games, naming the jobs keeps them readable instead of a wall of repetition: draw the player, check for a hit, add to the score.

Leaving a note

A good name says what a job is for. Where a name is not enough, write a note. Anything after a # is for people to read, and the computer skips it:

# The dashes have to match the width of the score panel.
DEFINE divider
  SHOW "----------"
END

Notes are worth most where they say why, not what. SHOW "----------" already says what the line does. Why ten dashes is the part a reader cannot work out.

When it’s wrong, see why

• Nothing happens when you call it. The name you called is not the name you defined. Check the spelling of both.
• You changed one thing and several changed. That is the other side of writing it once: every caller gets the change. If one caller wanted something different, it wanted its own job, or a job you can tell what to do.
• You cannot tell what a job does from its name. Rename it. A job called stuff costs you the thing you wrote it for.

What you’ve learnt

• A subroutine is a piece of work with a name, written once and called wherever you need it.
• DEFINE names the job. CALL runs it, and the program carries on from where it called.
• The value is say it once: one copy to read, one place to change.

What’s next

The divider does the same thing every time it runs. In Unit 3 a job takes a value and hands one back, which is what lets a single job do a whole family of things.