1. Software Engineering Fundamental data types

2. Guidelines - numbers Avoid “magic numbers” (hard- coded values that are not self- explanatory): Changes can be made more reliably Changes can be made more easily Code is more readable Comparefor(i = 0; i < 100; i++) withfor(i = 0; i < MAX_ENTRIES; i++)

3. Guidelines - numbers Avoid “magic numbers” (hard- coded values that are not self- explanatory): Exception: 0s and 1s, as in for(i = 0; i < MAX_ENTRIES; i++)

4. 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!

5. 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

6. Guidelines – floating point Floating point arithmetic is not real number arithmetic (never forget this)!

7. 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

8. 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

9. 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

10. 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)...

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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