Chapter 7: High Quality Routines

1. Chapter 7: High Quality Routines By Raj Ramsaroop

2. What Is A Good Routine? • A routine is a: • Function (C++). • Method (Java). • Procedure (Visual Basic). • Macro. • A routine should have a single purpose.

3. Example: A Bad Routine

4. Why Was That ABad 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.

5. Why/When Create A Routine? Biggest reason: reduce complexity. Minimize code, avoid duplicate code. Make your code more maintainable. Easier to read.

6. Why/When Create A Routine? Cont. • 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.

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

8. Can Code Sometimes Be Too Small For A Routine? • Depends: • If you keep repeating the same line. • One line of code can balloon into something bigger. • Makes code more readable.

9. Routine Cohesion • 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.

10. Unacceptable Types Of 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!

11. Naming Routines 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

12. How Long Should A Routine Be? 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.

13. Using Routine Parameters • 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).

14. When To Use A Function Or Procedure And Return Values 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.