1. Software Standards Specification
  2. Software Requirements Definition
  3. Software Best Practices
  4. Input Validation
  5. Output Validation
  6. Cookie Requirements
  7. Access Failure Error Checking
  8. Buffer Overflow
  9. Code Structure
  10. Software Functions
  11. Software Modules
  12. Requirements for Variables
  13. Software Code Comment Requirements
  14. Quality Code Requirements
  15. Software Code Review
  16. Software Code Testing Requirements
  17. Software Change Control

    Security Best Practices

  18. Secure Functional Requirements
  19. Account Creation
  20. Change Password
  21. Forgot Password
  22. Personal Question
  23. Contact Webmaster
  24. CAPTCHA Tests
  25. Answer Verification

Software Modules

A software module encapsulates related functions in a program together. It may encapsulate functions to:

  • Talk to database
  • Maintain a buffer
  • Control a network socket
  • Control access to an object or set of objects

When writing a software module it is important to be aware of what related the functions in the module together. You should also write the module so it could be used in other projects.

Modules typically have their own private data and multiple functions. Only the functions in the module can modify the private data in the module. The module may be constructed so it is an object such that multiple objects may be able to be instantantiated using the module.

Software modules should use the object oriented principle of encapsulation. This means that only variables that are part of module interfaces can be seen by outside modules or functions.

Module Interfaces

Modules are divided into a private implementation and a public interface. The implementation is hidden from external modules and functions. Interfaces must be created for the modules. The interfaces are used by other modules or functions to communicate with the module.


Headers define the functions in the module. The headers are normally in separate header files. Best practices for headers and modules:

  • Create one header for each specific source code module.
  • Include only one header in the source code module. The header included in the source code module should be the one designed for that module.
  • Define functions and data in the modules that are grouped into public or private sections. Public functions and data will be used as the interface to the module. The interface is used by other modules.
  • Do not allow hierarchies of nested or recursive includes of header files.
  • Create a common header file containing all definitions and macros that are typically used by all modules.
  • Include the commonly used header files in each module header.
  • Other than commonly used header files, only include headers of other files that are needed to use the interface function to that header. Set the compilation of the file included for the interface so only the public data is compiled.
  • Try to keep modules within 400 lines of code.

Using these rules, a change to one module's interface should not require the entire program to need to be recompiled.