0.4.8 Choosing a Data Type for Information

• 2.1f Types Revisited (8.75)

Start With What the Value Means

Choosing a data type begins with the information, not with the code.

A useful question is:

What kind of value can this information legitimately contain?

Consider several pieces of soccer information:

The meaning of each value suggests the kind of representation the program should use.

Use Text for Words, Labels, and Identifiers That Are Not Calculated

A player's name should be represented as text:

"Jordan"

A team name should also be text:

"Wildcats"

Some values made of digits may still be better treated as text.

For example, a code such as:

"007A"

is not necessarily a number simply because it contains digits.

If the program does not need arithmetic on the value, and leading zeros or letters matter, text may be the better representation.

Use Whole Numbers for Counts and Discrete Numeric Values

A whole-number type is a natural fit for values such as:

• goals scored;
• jersey number;
• number of players;
• number of substitutions.

For example:

goals = 3

A fractional value such as 3.5 goals would normally make no sense for a final goal count.

That makes a whole-number representation a strong match.

Use Fractional Numeric Types for Measurements That Need Decimals

Some values can contain a fractional part.

For example:

heightMeters = 1.82

or:

distanceMeters = 12.5

If the program needs to preserve the fraction, a whole-number type would lose information.

The type needs to support the range and precision required by the value.

At this stage, focus on the basic distinction:

whole number versus number with a fractional part.

Use Boolean Values for Yes/No State

Some information has two meaningful states.

For example:

isAvailable = true

or:

hasStarted = false

A Boolean communicates the intent much more clearly than arbitrary codes such as:

availability = 1

if 1 and 0 are merely being used to mean yes and no.

Clear types reduce the amount of hidden interpretation in the program.

Do Not Store Numbers as Text Without a Reason

Suppose a program stores goal count as:

"3"

That value is text.

If the program later needs to calculate:

goals + 1

it first has to convert the text into a number.

If the information is fundamentally numeric and enters the system as a number, storing it numerically is usually clearer.

Text is appropriate when the information is text.

Numeric types are appropriate when the information is truly numeric.

Do Not Use Numbers as Secret Codes for Meaning

Consider:

status = 1

What does 1 mean?

Available?

Injured?

Starting?

Captain?

The representation hides the meaning.

At this introductory stage, if the state is naturally true/false, use a Boolean.

If the value is text, use text.

More specialized named choices will be introduced later in programming coursework.

Think About the Operations You Need

The right type is also influenced by what the program needs to do.

If you need to:

add or compare quantities
use an appropriate numeric type.

If you need to:

display or manipulate words and characters
use text.

If you need to:

make a yes/no decision
use a Boolean.

The operations should fit the meaning.

A Type Choice Is Part of Abstraction

The real-world player is much more complex than the values stored by the program.

The system may choose to represent:

name
jerseyNumber
heightMeters
isAvailable

Each selected field is an abstraction.

Choosing a type adds another layer of precision.

The model now communicates both:

• what information matters;
• what kind of value represents that information.

A Simple Soccer Example

Suppose a lineup system needs:

playerName
jerseyNumber
goals
heightMeters
isAvailable

A reasonable introductory type plan is:

playerName     → text
jerseyNumber   → whole number
goals          → whole number
heightMeters   → fractional number
isAvailable    → Boolean

This does not tell you how the application will be coded yet.

It tells you what kinds of information the model needs to represent.

That type thinking becomes visible in UML class diagrams.