Software Engineering Fundamental data types Guidelines numbers Avoid

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: 0 s and 1 s, 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 == last. Index)). . . Better code: finished = ((index < 0) || (MAX < quantity)); repeated = (quantity == last. Index); 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