Reasons to Create Your Data Types:

Programmer-defined data types are a powerful programming tool. Creating your own data types allows you to increase the clarity and flexibility of your programs, and to facilitate information hiding. Below is a detailed list of reasons to create your own data types.

  1. Programmer-defined data types make your program easier to read. They can help to clarify your understanding of a program. Well-named programmer-defined data types can become almost self-documenting and therefore increase readability as well.
  2. Programmer-defined data types make your programs easier to modify. They can help you to keep up with changing requirements because they prevent excessive distribution of information. Modifications are easier to do if all the data-types are centralized in one place.
  3. Programmer-defined data types can be used for information hiding. Using your own data types can hide implementation details about the types of data you're using.
  4. Programmer-defined data types can increase the reliability of your program. In certain languages such as Pascal and Ada, you can define types with a range. This built in error-checking increases the reliability of your program.
  5. Programmer-defined data types can also be used to make up for language weaknesses. Using programmer-defined data types, you can create types such as boolean that don't exist in all languages.


Guidelines for Creating Your Own Types

  1. The type name should reflect what the function of the type is. Avoid referring to computer data types, such as long and integer, and focus on the real world object the type represents.
  2. Try to avoid using pre-defined types. By exclusively using your own data types, you can anticipate and prepare for the possibility of change. Exclusively using your own data types allows your variable declarations to become close to self-documenting.
  3. Don't use a programmer-defined type to re-define a predefined type. Using names that usually represent predefined types, creates confusion and hinders readability.
  4. Use your simple programmer-defined types to create more complex data structures. This will extend the flexibility of your simple types and promotes information hiding.

See Code Complete Sections 8.2 & 8.3 pages 173-177

Choosing Good Variable Names

Using good names for your variables is a part of defensive programming. Clear, concise variable names increase readability and comprehension of your programs. Below is a list of general considerations that should go into choosing your variable names.

  1. A name should be chosen that completely and accurately describes the concept that the variable represents.
  2. Names should describe what something represents, not how it is used. Avoid computer science-"isms".
  3. Names should not be too long or too short. For example a name could be from 1 character to 255 characters.  But having a variable name 1 is to small, if we where to use 'X' it doesn't say much about it variable or if we were to use 'MaxNumberOfYearsAStudentCanTakeEnglish' is to long.  The general goal in choosing a name is make is short as possible but descriptive as possible.  So a better name for  'MaxNumberOfYearsAStudentCanTakeEnglish' would be 'MaxEnglishFails' or 'MaxEnglishTries'.  It says what the long one does, but it is more concise.
  4. Establish or adopt a naming convention and always state the naming convention you are about to use in the comment at the start of your program.  If you are establishing one, clearly state what each one of the entries represent.


Choosing Loop Variable Names

  1. It is okay to use short names such as the conventional i, j, and, k when a loop is very simple and short.
  2. Variables that are also used outside the loop should be given meaningful names to increase readability.
  3. If loops are nested, use meaningful variables to prevent confusion and increase readability. Never use i, j, ect in nested loops!


Choosing Status Variable Names

  1. When using "flags", give them meaningful names and assign them values. For clarity, "flags" should be tested against enumerated types or named constants.


Choosing Names for Temporary Variables

  1. Because all variables are essentially temporary, it does not make sense to differentiate some with names such as "temp". Always use meaningful names, even for "temporary" variables.


Choosing Boolean Variable Names

  1. Try to use conventional boolean names when possible. For example: Done, Error, Found etc.
  2. Give boolean variables names that are obviously true or false. This helps to clarify what the variable is used for.
  3. Only use positive boolean names. This will avoid double negatives.


Choosing Enumerated Type Names

  1. For clarity, use a prefix or suffix on all members of a type that belong to the same group. This will prevent confusion and enhance readability.
    For example: defining different types of error called SYSTEM_ERROE, PRINTING_ERROR, ect.


Choosing Constant Names

  1. Use the name to represent the abstract entity rather than the quantity it holds. This will increase readability.


Good Naming Convention (Language Independant)

  1. Identify Global variables with a g_ prefix. Example: g_RunningTotal
  2. Identify Module variables with a m_ prefix. Example: m_TotalScore
  3. Identify Types with a _t suffix. Example: Coordinate_t
  4. Identify Constants by using the C standard uppercase or by using a _c suffix. Example: FILE_SIZE or FileSize_c
  5. Identify Enumerated types with a _e suffix. Example: Coinage_e
  6. Identify Input only variable names with an IP suffix. Example IPMax
  7. Stick with consistant naming, use either alternating case of use _'s, not both

See Code Complete Sections 9.1 & 9.2 pages 185-196.

The following are examples of well-designed programs:
C Program
C++ Program
Java Program

Here are some sample programs of what not to do when creating and naming data types:
C Program
C++ Program
Java Program


Reference: Code Complete, Steve McConnell, Microsoft Press (1993).
Prepared by: Cherie Johns
               Chris Johnson
               Lana Sesula
               Micheal Gibney
               Tanya Douglas

Revised by: Chantel Laplante
               Chris Mills
               Graeme Humphries
               Melvin Lenz
               Mohat Gupta


     
Last Modified: Thursday, 08-Jun-2000
Copyright 2000 Department of Computer Science, University of Regina.

[CS Dept Home Page]