Chapter 7: High Quality RoutinesBy Raj Ramsaroop

A routine is a: Function (C++). Method (Java). Procedure (Visual Basic). Macro.

A routine should have a single purpose.

What Is A Good Routine?

Example: A Bad Routine

Name: HandleStuff(). Too many parameters. No logical ordering to parameters. Looks like it’s trying to do more than one

task. Not logically laid out. Input variable is changed. Unused parameters.

Why Was That A Bad Routine?

Biggest reason: reduce complexity. Minimize code, avoid duplicate code. Make your code more maintainable. Easier to read.

Why/When Create A Routine?

Avoid duplicate code. Only need to check one place. Avoid writing the same thing twice. Similar code in different routines – split them

up. Hide sequences.

Keeps code simple. E.g. if you get data from a user and data from

a file, neither routine should depend on each other.

Why/When Create A Routine? Cont.

Improve portability. Make your code independent of

hardware/software, or the project you are working on.

Can be reused – enforces object-oriented concepts.

Simplify complicated boolean tests. E.g. isVisible() Details of the test are out of the way. The name is descriptive. Emphasizes it’s significance.

Why/When Create A Routine? Cont.

Depends: If you keep repeating the same line. One line of code can balloon into something

bigger. Makes code more readable.

Can Code Sometimes Be Too Small For A Routine?

Cohesion refers to how closely the operations in the routine are related.

Ensures routines perform one task well – and nothing else.

Acceptable types of cohesion: Functional cohesion – the best type, is when a

routine performs only one function. Sequential cohesion. Communicational cohesion. Temporal cohesion.

Routine Cohesion

Procedural cohesion – operations that are in a specific order and are combined for that specific reason.

Logical cohesion – basically methods with big ‘if statements’ Operations are not usually logically related. Only time this would be acceptable would be

something like an event handler. Coincidental cohesion – if you have this it probably

means you need to redesign your program!

Unacceptable Types Of Cohesion

Name can be as long as it needs to be – as long as it doesn’t sound silly!

Make it descriptive. Avoiding meaningless verbs (e.g. processOutput(),

calculateData()). Don’t differentiate functions solely by a number! Use what the function returns to name the function. E.g.

customerId.next(), printer.isReady() To name a procedure, use a strong verb followed by an

object. E.g. printReport(), calculateInvoice() Use opposites such as get/set, open/close, first/last etc

Naming Routines

A line is a noncomment, nonblank line of code.

Book suggests up to 200 lines. They can be as long as they need to be as

long as you focus on cohesion.

How Long Should A Routine Be?

Put parameters in “input-modify-output” order. As opposed to randomly or alphabetically. Implies a sequence of operations.

If several routines take similar parameters, put them in the same order.

Use all parameters. Status and error variables go last. Don’t use routine parameters as working variables. Document the input variables (range, units, values that should

never appear etc). Limit number of parameters to 7. Check parameter types (mismatched types etc).

Using Routine Parameters

A function is a routine that returns something.

A procedure is a routine that does something, but does not return anything.

You can combine the two. Return values should return an object, not a

reference or pointer to local data.

When To Use A Function Or Procedure And Return Values