01 | WHY CHECK DATA BEFORE USING IT?

A teacher enters a test mark into a school system. The test is out of 50, but the entered mark is 500. The program might be able to store that number, yet it does not make sense under the test’s rules.

Validation checks whether data meets specified acceptability rules. A range rule can reject 500 because permitted marks are from 0 to 50.

Without appropriate checks, a booking system might accept a negative capacity, a program might receive letters where it needs a number, or a required identifier might be missing. These inputs can lead to incorrect decisions or failed calculations.

This lesson introduces four checks: range, length, type and presence. Each asks a different question. Choosing the right check means understanding both the data and the rule it needs to satisfy.

02 | VALID DOES NOT NECESSARILY MEAN CORRECT

Suppose a student actually scored 34, but the teacher enters 43. A range check from 0 to 50 accepts 43. It is within the permitted range, but it is not the student’s correct mark.

Validation establishes acceptability under the checks performed, not factual accuracy. A valid value can still belong to the wrong student, contain an undetected typing error or be based on incorrect information.

The opposite also matters: whether data is acceptable depends on the scenario. An age of 120 might be outside a particular school-form rule but not outside every possible database’s rule.

A clear explanation is: “The range check rejects impossible marks for this test, but cannot detect every incorrect mark because another wrong value might still lie within the accepted range.”

Later lessons distinguish validation from verification, which checks that data has been copied or entered as intended.

03 | RANGE CHECK: TEST THE VALUE AGAINST LIMITS

A range check checks whether a value lies within specified limits. A test mark might be acceptable from 0 to 50 inclusive.

Inclusive means the endpoints are allowed. Zero and fifty both pass. Minus one and fifty-one fail.

The condition is Mark >= 0 AND Mark <= 50. Both comparisons must be true: the mark must meet the lower limit and the upper limit.

A range rule does not by itself prove that the value is a whole number. A numeric value of 12.5 lies inside these limits, so a system requiring whole marks also needs a suitable type rule.

State the limits in your answer. “Use a range check” identifies the check, but “accept whole marks from 0 to 50 inclusive” explains the proposed rule.

04 | GET THE LOGIC AND BOUNDARIES RIGHT

At the lower boundary, evaluate both comparisons: 0 ≥ 0 is true and 0 ≤ 50 is true. At 51, the second comparison is false.

Using Mark > 0 AND Mark < 50 would reject both endpoints. That is wrong if the requirement includes zero and fifty.

Using OR instead of AND between the inclusive comparisons also fails. A mark of 500 is at least zero, so OR would accept it despite exceeding fifty.

A rejection condition can instead be written Mark < 0 OR Mark > 50: either violation is enough to reject the value.

// Mark is already numeric
IF Mark >= 0 AND Mark <= 50
  THEN
    OUTPUT "Within the permitted range"
  ELSE
    OUTPUT "Outside the permitted range"
ENDIF

This fragment assumes Mark already contains a numeric value. Handling text such as “ten” requires a separate type-checking or input-conversion step before these numeric comparisons.

05 | LENGTH CHECK: COUNT CHARACTERS

A length check checks how many characters a value contains. It may require an exact length, a minimum length, a maximum length or a permitted interval.

A school code might require exactly six characters. ABC123 has six characters and passes that length rule. AB123 has five and fails; ABC1234 has seven and fails.

Length concerns characters, not numeric magnitude. A six-character identifier is not the same idea as a number below six. Keep identifiers as text when their characters, including leading zeros, must be preserved.

A length rule alone does not check which characters are allowed. Six question marks have length six too. Checking the required pattern is a format check, covered in the next lesson.

Do not infer a universal length requirement from these examples. The permitted lengths must come from the actual system requirements.

06 | REPRESENT A LENGTH CHECK PRECISELY

Cambridge pseudocode uses LENGTH() to obtain the number of characters in a string. LENGTH(Code) produces a count; comparing that count with six performs the check.

DECLARE Code : STRING
INPUT Code
IF LENGTH(Code) = 6
  THEN
    OUTPUT "Length accepted"
  ELSE
    OUTPUT "Enter exactly six characters"
ENDIF

The condition uses = for comparison. It does not change the code or alter its length.

For text that may contain from 2 to 30 characters, a condition could be LENGTH(Text) >= 2 AND LENGTH(Text) <= 30. Again, both limits matter.

A successful length check does not prove an identifier exists in the school’s records. It establishes only that the input meets this particular character-count rule.

07 | TYPE CHECK: IS IT THE REQUIRED KIND OF VALUE?

A type check checks whether data is of the required kind, such as a whole number for a quantity or a numeric value for a measurement.

If Quantity must be an INTEGER, 3 is suitable, while 3.5 and the text “three” are not. A REAL measurement can allow fractional values such as 3.5.

Type and range are separate. Minus three is an integer, so it meets the whole-number type requirement. It might still fail the range rule for an order quantity that must be from 1 to 20.

A numeric entry screen often receives raw characters before converting them into a number. Checking whether that input can be interpreted as the required type is part of the application’s input handling. Declaring an INTEGER variable alone does not establish that arbitrary user text has passed a complete validation routine.

08 | DO NOT CONFUSE AN IDENTIFIER WITH A QUANTITY

An identifier can contain digits without being a quantity to calculate with. A locker code such as 004219 may need to remain a six-character STRING so that its leading zeros are preserved.

Converting it to the integer 4219 changes its representation. If exact character length is important, that can cause problems.

Similarly, a telephone number is usually treated as text in a form because punctuation, prefixes and leading zeros may matter. It is not ordinarily a quantity that should be added or averaged.

Choose the type from the meaning of the field. A quantity of books is naturally a whole number; a book identifier may be text even when some identifiers contain only digits.

A digit-only rule for a text code is a character or format requirement, not proof that storing the code as an integer is appropriate.

09 | PRESENCE CHECK: HAS ANYTHING BEEN SUPPLIED?

A presence check checks whether required data has been provided. A booking form may require a student identifier before it can proceed.

A blank field fails a presence check. A non-empty field can pass even if its contents are wrong, too short or of the wrong type.

The empty string is written "": two quotation marks with no characters between them. Testing StudentID <> "" checks that the string is not empty.

DECLARE StudentID : STRING
INPUT StudentID
IF StudentID <> ""
  THEN
    OUTPUT "Data supplied"
  ELSE
    OUTPUT "Student identifier required"
ENDIF

In a real form, spaces may need special handling. A field containing only spaces is not the empty string; a system may trim whitespace before applying its presence rule. That behaviour must be specified rather than assumed from the simple condition.

A presence check does not establish that an entered student identifier belongs to a real student. It only establishes that something was supplied under the chosen rule.

10 | CHOOSE CHECKS THAT WORK TOGETHER

A canteen order quantity must be supplied, must be a whole number and must lie from 1 to 20 inclusive. No single one of these checks covers every requirement.

Presence catches a missing input. Type catches “three” or 3.5 when a whole number is required. Range rejects 0, −1 or 21 once the value has been safely interpreted as a number.

Do not attempt numeric comparisons on arbitrary raw text before checking or converting it appropriately. The input routine must handle missing or non-numeric entries without simply crashing.

Some checks overlap. An exact positive length rule also rejects an empty string. Naming several checks is not automatically better; explain what each contributes to the actual field’s requirements.

11 | DECIDE WHAT HAPPENS WHEN A CHECK FAILS

A check needs a response. The program might reject the entry, show a useful message and ask again. It should not proceed with a value that fails a required rule.

For numeric whole-mark input, this range-checking loop asks again until the value lies within zero to fifty.

DECLARE Mark : INTEGER
// Assume every entry is a whole number
REPEAT
    OUTPUT "Enter a mark from 0 to 50"
    INPUT Mark
    IF Mark < 0 OR Mark > 50
      THEN
        OUTPUT "Outside range: try again"
    ENDIF
UNTIL Mark >= 0 AND Mark <= 50
OUTPUT "Range accepted: ", Mark

REPEAT runs the input at least once. UNTIL stops when both range comparisons are true. If the user enters 51 and then 34, the first value is rejected and the second remains in Mark when the loop finishes.

This example deliberately assumes every entry is already a whole number. It illustrates range retries, not a complete type-validation routine. There is no invented universal Cambridge keyword called “TYPECHECK” hidden in the example.

A helpful message explains the accepted rule, such as “Enter a whole-number mark from 0 to 50”, rather than just saying “Error”.

12 | VALIDATE WITHOUT SILENTLY CHANGING THE MEANING

Suppose someone enters 75 as an order quantity when the maximum is twenty. Silently changing it to twenty is not the same action as rejecting it.

The user may have entered the wrong field or intended a different order. A program should follow its specified response rather than inventing a replacement value.

Some systems deliberately normalise input, such as trimming surrounding spaces, before checking it. That can be useful when agreed, but the transformation must suit the data. Removing leading zeros from an identifier may change its meaning.

Validation rules should match the purpose. A required comment field and a numeric quantity have different needs. Asking “Which check is best?” without identifying the field and requirement is incomplete.

13 | TEST ACCEPTED AND REJECTED INPUTS

For a range of zero to fifty, test an ordinary accepted value such as 34, both accepted endpoints 0 and 50, and the nearby rejected values −1 and 51.

For exact length six, test five, six and seven characters. For an integer quantity, test a whole number, a fractional value and non-numeric text. For presence, test an empty field and a supplied value.

Compare actual behaviour with the expected rule. Does the program show the right message, request replacement input and prevent rejected data from being used?

Later lessons cover test-data categories in detail. Here the goal is to make the intended validation boundary clear and exercise both pass and fail cases.

14 | EXPLAIN THE CHECK AND ITS LIMIT

For a describe question, state what the check tests. For an explain question, connect the rule to its purpose and limit.

For example: “A range check compares the mark with zero and fifty inclusive, so values outside the test’s possible score range are rejected. However, a wrong mark such as forty-three can still pass because it lies within those limits.”

A useful length explanation is: “The student code must contain exactly six characters; the check rejects shorter or longer entries, but it does not establish that the characters follow the required pattern.”

You should now be able to choose and justify these four checks, write simple range, length and presence conditions, and avoid claiming that valid data must be accurate. The next lesson adds format checks and check digits.