Game Development Reference
To many critics, coding standards pay too much attention to the format of the code
rather than its substance. On the other hand, there must be some reason why devel-
opment tool companies continue to provide more and more coding assistance using
visual means such as colors and graphs. Both have the same goal in mind: to help the
developer get the code right the first time.
Even so, coding standards aren't just about formatting. Many of the rules are designed
to address important issues such as portability, clarity, modularity, and reusability.
The importance of these standards is magnified in a project that is distributed across
different teams, sites, and countries. There are few things less fun than tracking down a
defect caused by one team defining SUCCESS as 0 and another team defining SUCCESS
Here are some excerpts from the C Coding Standards for the Computer Associates
Ingres ® project:
Do not use constants to check for machine dependent ranges or values. Use the
symbolics instead (For example: UINT_MAX not 4294967295 ).
Constants must be properly typed to match their usage. For example, a constant
1 that will be passed to a procedure expecting a long must be defined as ((long)1) .
Do not use the literal zero as a NULL pointer value.
Use TYPEDEF , not #define , to declare new types.
As a tester, you should be aware that these standards also give clues as to how code will
fail under certain situations. For example, if machine-dependent ranges are hard-
coded, you will see the resulting failure on one type of machine but not on another.
So, features that depend on values that could be machine dependent should be tested
on different machines.
In a QA role, your responsibility is to check that the programmers have coding stan-
dards which they apply to their code. This is typically done by sampling files from the
game code and doing a manual or automated check against the appropriate standards.
If you are doing QA on behalf of a publisher or third-party QA group, you can still do
this by gaining access to the programmer's standards, tools, and files. Alternatively,
you could require the programming team to submit evidence, such as printouts, that
they did this checking themselves.
How good is “good�? game software? Certainly the amount of defects in the code has
something to do with goodness. The team's ability to find defects in its product is
another factor to consider. A “sigma level�? establishes the defectiveness of game code