Office of Information Services - Application Programming
Subroutines -- Internal Subroutines
Overview
Internal Subroutines can be a very useful thing in a program. In InfoBasic
they should primarily be used to avoid duplicating code within a program. A
large percentage of InfoBasic programs are relatively short (100-200 lines of
code) and perform only 1 to 2 processing actions. For these types of programs
internal subroutines should rarely be used. Keeping programs linear in terms
of reading usually make them easier to maintain. Rather than using internal
subroutines for these programs use "white space" (blank lines or * lines) to
separate the program into logical groups of coding.
Naming Subroutines
- NEVER use numbers to designate subroutines
- Internal subroutines should be identified by names which imply
something of what the subroutine does
- Subroutine names should be kept a short as possible, while maintaining
their meaningfulness
DO use:
- GOSUB CALCULATE.PAY
- GOSUB CHECK.DATES
- GOSUB GET.ID
- GOSUB PIECE.OF.CAKE
DO NOT use:
- GOSUB 10
- GOSUB 1000
- GOSUB XYZ
- GOSUB THIS.IS.NOT.THE.WAY.TO.NAME.A.SUBROUTINE.BECAUSE.IT.IS.TOO.LONG
When to use Internal Subroutines
- Generally there is an inverse correlation between the number of lines in a
subroutine and the number of times those lines would be repeated in the main
program in determining whether to use an internal subroutine. In other words,
the more lines of code being repeated, the fewer times it needs to be repeated
in order to justify using an internal subroutine.
- NEVER use an internal subroutine for only 1 or 2 lines of code
- 3-4 lines of code shoule be repeated 3-4 times before needed to put into an
internal subroutine
- 5-6 lines definitely should be a subroutine if they are used 3 or more times
in the program
- More than 6 or 7 lines of codes should almost always constitute an internal
subroutine if they are used 2 or more times with the same program.
The one exception to the above is when you have a significant group code (8-10
lines or more) which need to be done and can stand alone, but which would
have a negative impact on the flow of reading the program. See XX for an
example.
Leaving the Subroutine
- The only correct way to leave a subroutine is through a RETURN
- Avoid going deeper than 2 subroutines before returning to the main program
- Avoid using several RETURNs in a subroutine. If you
find yourself using several RETURNS, try setting flags (i.e., @TRUE and @FALSE)
and checking the along the way to avoid code, breaking the subroutine up into
component parts to make several subroutines, or labeling and pointing to one RETURN at the end of a
subroutine
- NEVER NEVER NEVER leave a subroutine by doing a GO or a GO TO
Administrative Programming Main Menu
Programming Projects-
Programming Standards-
Tools Library