Software Engineering

Linear code Conditionals

Linear code

1. Statements that must be in a specific order.

2. Statements whose order does not matter.

Linear code

Statements that must be in a specific order: Key issue: dependency – statements

must be executed in a specific order if each statement depends on the previous one(s).

Data = ReadData();Results = CalculateResultsFromData(Data);PrintResults(Results);

Linear code

Statements that must be in a specific order: Organize code so that dependencies are

obvious. Name routines so that dependencies are

obvious. Use routine parameters to make

dependencies obvious (e.g. simulate “assembly line”, as in previous example).

Linear code

Statements that must be in a specific order: Document unclear dependencies with

comments. Check for dependencies with

assertions or error-handling code, e.g. boolean variables whose state characterises whether the code has passed through certain points.

Linear code

Statements whose order does not matter: Make code that can be read from top to

bottom:Bad code Better codeStudentData student; StudentData student;LecturerData lecturer;student.ComputeEvaluation();lecturer.ComputeCourses(); student.Print();student.ComputeEvaluation(); LecturerData lecturer;student.Print();lecturer.ComputeCourses();lecturer.Print(); lecturer.Print();

Linear code

Statements whose order does not matter: Group related statements:

Bad code grouping Better code grouping

Linear code – key points

Major principle: ordering dependencies. Dependencies should be made obvious

through routine names, parameter lists, comments, and if necessary housekeeping variables.

If code does not have order dependencies, keep related statements as close together as possible.

Conditionals

IF-THEN statements.

IF-THEN-ELSE statements.

IF-THEN-ELSE-IF... chain statements.

Conditionals

IF-THEN statements: Write the nominal path through the code first;

then write the unusual cases. Make sure that you branch correctly on

equality – e.g. be careful with > instead of >=.

Consider the ELSE clause, even if you do not need it. Write an empty ELSE to make clear to the reader that you have considered it. Insert comments if appropriate.

Conditionals

IF-THEN-ELSE statements: Put the normal case after the IF rather than

after the ELSE. Do not mix normal cases and error cases,

especially when you are writing nested IF-THEN-ELSE statements.

Follow the IF clause with a meaningful statement. Do not write empty IF clauses.

Test the ELSE clause for correctness. Careful! Check for reversal of IF and ELSE.

Conditionals

Chains of IF-THEN-ELSE statements: Consider using CASE statements. Simplify complicated tests with boolean

function calls. Put the most common cases first. Make sure that all cases are covered. If

appropriate, add a final ELSE clause to take care of unplanned for cases.

Conditionals

CASE statements: Order your cases appropriately. Some

alternatives for ordering are: Order cases alphabetically or numerically. Put the normal case first, and the exceptional

cases last. Order cases by frequency, from more frequent to

less frequent ones.

Conditionals

CASE statements: Keep the actions of each case as simple as

possible. CASE statements should be used for simple

data and many alternative paths of choice. If your data is not simple, consider using chains of IF-THEN-ELSE.

Conditionals

CASE statements: Use the DEFAULT clause only for legitimate

defaults. NEVER use the DEFAULT clause simply for the last case.

Use the DEFAULT clause to detect errors, if it is not being used for some other purpose.

Make sure you “break out” of the CASE at the end of each considered case. For example, in C, C++ or JAVA, make sure that the end of each case has a BREAK.