Transcript What are the Data Type pitfalls?

Software Engineering

Fundamental data types
Guidelines - numbers

Avoid “magic numbers” (hardcoded values that are not selfexplanatory):



Changes can be made more reliably
Changes can be made more easily
Code is more readable

Compare
for(i = 0; i < 100; i++)
with
for(i = 0; i < MAX_ENTRIES; i++)
Guidelines - numbers

Avoid “magic numbers” (hardcoded values that are not selfexplanatory):

Exception: 0s and 1s, as in
for(i = 0; i < MAX_ENTRIES; i++)
Guidelines - numbers




Anticipate divide-by-zero errors
Make type conversions explicit
whenever needed to make them
obvious to the reader of your code
Avoid mixed-type comparisons
Pay attention to your compiler
warnings!
Guidelines - integers



Check for integer division (integer
arithmetic differs significantly from
floating point arithmetic at this
point)
Check for integer overflow
Check for overflow in intermediate
calculations
Guidelines – floating point
 Floating
point
arithmetic is not real
number arithmetic
(never forget this)!
Guidelines – floating point




Avoid additions and subtractions on
numbers that have greatly different
magnitudes
Avoid equality comparisons
Anticipate rounding errors
If your language provides specific
support for specific data types (e.g.
currency), use it
Guidelines – characters and
strings

Avoid “magic characters” and
“magic strings”


Centralise them as values of variables
instead
Decide on internationalisation/localisation
strategies as early as possible in the
lifetime of a program
Guidelines – characters and
strings


Know how your language and
environment support Unicode; if you
need to support multiple languages,
use Unicode
Decide on a consistent conversion
strategy among string types
Guidelines – booleans

Use boolean variables to “document”
your program and simplify complicated
tests


Unclear code:
if ((index < 0) || (MAX < quantity) || (quantity
== lastIndex)) ...
Better code:
finished = ((index < 0) || (MAX < quantity));
repeated = (quantity == lastIndex);
if (finished || repeated) ...
Guidelines – enumerated
types


If available in your language, use them
If not, you can still simulate them




Use them for readability
Use them for reliability
Use them for modifiability
They can be good alternatives to plain
Boolean
Guidelines – enumerated
types




Check for invalid values
Define first and last entries for use as
loop limits
Reserve first entry (that should come
even before first) as invalid
Use first, first and last consistently
along the project
Guidelines – named constants


Use them, they are a nice way to
eliminate “magic numbers”
Use them consistently, NEVER use a
named constant in one place and a
literal representing the same value in
another
Guidelines – arrays





Make sure that all array indices are
within the bounds of the array
Check the end points of arrays
Make sure indices of multidimensional
arrays are used in the correct order
Watch out for index “cross-talk”
Consider using containers – sets,
stacks, queues, etc. - instead of
arrays
Guidelines – type aliasing

Type aliasing refers to creating alias
names to existing types or to
subsets of existing types




typedef in C++
Clearer code
Centralised type modifications
Improved reliability
Guidelines – type aliasing




Create types with functionally
oriented names, i.e. names that
refer to the problem instead of the
solution, storage organisation, etc.
Avoid predefined types. Use your
own types as much as you can
Do not redefine a predefined type
Consider creating a class instead of
a typedef