User-defined data types — common mistakes

Examiners are very particular about syntax. Always remember to include TYPE and ENDTYPE. When declaring fields, use $DECLARE <Identifier> : <DataType>$. When accessing fields, the dot . is crucial. It's also a common convention (though not mandatory) to prefix type names with a 'T', like TStudent or TBook, to make your code more readable.

While you could store data in parallel arrays (e.g., an array for names, an array for IDs), a record is far superior. It encapsulates all data for a single entity, making your code more readable, maintainable, and less prone to errors. With parallel arrays, it's easy to mix up indices and mismatch data; with an array of records, all data for Student[5] is guaranteed to belong to the same student.

TYPE is used to define a blueprint for a new data type. It doesn't create any variables or allocate any memory. DECLARE is used to create an actual variable (an instance) based on a data type (either built-in or user-defined) and allocates memory for it.

Yes, absolutely. This is called a nested record. For example, a TStudent record could have a field DateOfBirth which is itself a record of type TDate (containing Day, Month, and Year fields). This is a powerful technique for modelling complex hierarchical data.

This is a subtle point. In many languages, a string is treated as a composite type because it's a collection of characters. In the context of Cambridge pseudocode, it's generally treated as a basic type for declaration purposes, but it's good to be aware that it's fundamentally an array or sequence of CHARs.