Defensive Design

Two audiences, one instinct

This topic looks like eight words to memorise and it is really one habit applied twice. Defensive design asks what will go wrong when somebody else uses your program. They will type a letter where you expected a number, leave a box empty, or try something you never imagined because they do not know what you imagined. Maintainability asks what will go wrong when somebody else reads your program, and that somebody is usually you in six months, with no memory of why any of it is the way it is. Both questions are asked in advance, which is what defensive means. And there is one more thing to hold on to, because it is where the marks are on this topic. Naming a technique gets you almost nothing. Every question wants what the technique buys, and there are three answers that keep coming back: it lets you reuse code, it makes the program easier to test, or it makes it easier to read. Get into the habit of finishing every sentence with one of those.

Words for defensive design

Five terms. Notice that each definition ends with what the technique is for, which is the habit the whole module is trying to build.

Match the technique to what it buys you

What each technique is for

A program crashes when a user types their name into a box that expects their age. Which technique would have prevented it?

• Input validation, because the entry would have been checked for type before it was used
• Authentication, because the program would know who the user was
• Using a sub-program, because the code would be better organised
• Commenting, because the intention would have been clear

Complete the validation check

A password must be at least 8 characters. To reject anything shorter, write IF length _____ 8 THEN OUTPUT too short. A score must be between 0 and 10 inclusive, so to accept it write IF score _____ 0 AND score _____ 10 THEN. A username must not be left empty, so to reject an empty one write IF length _____ 1 THEN OUTPUT required. Every one of these refuses bad data _____ the program tries to use it.

Guarding the user, guarding the reader

The two halves of this topic protect against two different people. Setting them side by side is the fastest way to remember which technique belongs where.

Validation or authentication

Select the TWO checks that are input validation rather than authentication.

• Refusing a date of birth that would make the user more than 120 years old
• Refusing a postcode that is too short to be a real one
• Asking for a password before allowing access to an account
• Sending a code to a phone to confirm the user is the account holder

Naming a technique earns nothing

This is the single most reliable way to lose marks here, and the specification says so almost in as many words. A question asks why a programmer used sub-programs, and the answer comes back that it makes the program more maintainable. That has restated the question. Maintainable how, and to whose benefit? The answer that scores says the sub-program can be called from several places so the code is not repeated, and can be tested on its own without running the whole program. Keep three words in reach and finish every sentence with one of them: reuse, testing, readability. Sub-programs give you the first two. Naming conventions, indentation and commenting give you the third. And one thing worth knowing about comments in particular: a comment that says what the line already says is worth nothing, because anyone reading it can see the line. A comment that says why the line is there, or why it was done this way rather than the obvious way, is worth a great deal.

Trace the validation loop

This program checks four scores and counts how many are valid. The four values entered, in order, are 7, 15, 3 and -2. Dry-run it and fill in the blank cells.

The line that is not validation

Four lines from a program. Select the ONE that is NOT input validation.

• IF length < 8 THEN OUTPUT password too short
• IF age > 120 THEN OUTPUT please check that date
• total <- total + score
• IF quantity < 1 THEN OUTPUT enter at least one

The same code, made readable

Here are two versions of the same few lines, doing exactly the same thing. The first reads: x <- 0, then FOR i <- 1 TO n, then IF a[i] > 0 THEN x <- x + 1 ENDIF, then NEXT i. Everything about it works, and nobody reading it in six months has any idea what it is counting. The second reads: positiveCount <- 0, then FOR index <- 1 TO readingCount, then IF readings[index] > 0 THEN positiveCount <- positiveCount + 1 ENDIF, then NEXT index. Not one instruction has changed; the program does the same thing at the same speed. What changed is that a reader can now tell what is being counted without tracing back to find out. That is what naming conventions buy, and it is the whole of the answer to why they matter. Two more points. Indentation did the same job here without a single word: the indented line is visibly inside the loop. And if you were to add a comment, do not write that this counts positive readings, because the names already say so. Write why positive readings matter, or why zero is being excluded, because that is the thing the code cannot tell anyone.

The order to check things in

Put the checks in the order a well-designed program applies them when a user submits something.

• Confirm the user is who they claim to be before anything else
• Check the entered data is of the type the program expects
• Check the value is within a sensible range or length
• Refuse the entry with a clear message if either check fails
• Use the data, now that it is known to be safe to use

Say technique and payoff together

Assemble the sentence pattern that earns the mark.

A form that gets abused

A booking program keeps failing because of what people type into it. Take the design decisions in order.

• Users are entering text where a number of tickets is expected, and the program crashes. What do you add?
• Someone books ten thousand tickets by mistake. What kind of check is missing?
• The same validation code has been copied into four places. What should be done and why?
• A colleague asks you to justify the change in one sentence. What do you say?

Explain the techniques and why

A program takes bookings from the public and is going to be maintained by someone who did not write it. Explain what defensive design and maintainability techniques it should use, and why each one helps.

• Explain what anticipating misuse means, and give one example of a misuse worth anticipating
• Explain the difference between authentication and input validation, with an example of each
• Give one validation check the booking program should make, and say what it refuses
• Explain why sub-programs help, naming both of the payoffs they give
• Explain what naming conventions and indentation each do for a reader
• Explain what makes a comment worth writing, and what makes one worthless
• Finish every explanation with reuse, testing or readability rather than the word maintainable on its own