Understand the built-in data types: integer, real or float, Boolean, character and string, and understand records, arrays and user-defined data types built from them.

What this dot point is asking

AQA wants you to name and describe the built-in data types (integer, real or float, Boolean, character and string), say what each stores and how much memory it typically uses, and explain how composite and user-defined types (records and arrays) are built from these primitives.

The built-in data types

• Integer: a whole number with no fractional part, for example 42 or -7. Stored in pure binary (unsigned) or two's complement (signed), typically in 16, 32 or 64 bits.
• Real or float: a number that may have a fractional part, for example 3.14. Stored in floating point as a mantissa and an exponent.
• Boolean: one of two logical values, True or False. Needs only a single bit, though languages often store it in a whole byte for addressing convenience.
• Character: a single symbol such as 'A', '7' or '?'. Stored as a numeric code using a character set such as ASCII or Unicode.
• String: an ordered sequence of characters, for example "hello". Stored as the characters in order, often with a length count or an end marker.

These primitive types connect directly to the data representation topic: an integer is exactly the binary representation studied in 4.5, a real is floating point, and a character is an ASCII or Unicode code. The data type is therefore not just a label; it tells the compiler how to interpret the bits in memory, so the same bit pattern means a different value as an integer, a real or a character.

Composite and user-defined types

User-defined types matter because they let the program speak the language of the problem rather than of raw primitives. Defining a Date record with day, month and year fields, or an enumerated Suit type with the values hearts, diamonds, clubs and spades, makes code more readable and lets the type system reject impossible values. This is closely related to abstraction: a well-chosen type hides irrelevant detail and exposes only the meaningful operations.

Choosing the right type

Using the correct type saves memory and prevents errors. Storing an age as a Boolean would lose information; storing a price as an integer would lose the pence; using a 64-bit integer where an 8-bit one suffices wastes memory across millions of records. A type also restricts operations: you can add two integers, but adding two Booleans is meaningless, so the type system catches the mistake at compile time rather than letting it corrupt results at run time. This is why selecting types thoughtfully is treated as a genuine design skill, not a formality.