Game Development Reference
In-Depth Information
'
is that you
re consistent. If you choose method #1, I should never see a function in
your code base that doesn
'
t conform to that style. You might think it
'
s a relatively
minor topic, but when you have a code base with millions of lines of code written
by dozens of different people, consistency becomes extremely important.
One important exception to this is when integrating code written by a third party.
You don
t want to change every single line to match your style because every
time you update that code, you
'
ll have to make those changes all over again. Make
sure that all such code is isolated from your main code base. If you look at the source
code for this topic, you can see a really good way of doing this. All third-party
code and libraries live in the Source/GCC4/3rdParty directory.
Another very important place to be consistent is in general API and function naming
conventions. For example, if you have a number of classes that require an update
every frame, the update function should be named the same thing across all of
these classes and probably have the same signature. For example, here
'
'
s the signature
for the update function in the
Process
class you
'
ll see later:
virtual void VOnUpdate(const int deltaMilliseconds);
Here
'
s the update for the
HumanView
class:
virtual void VOnUpdate(const int deltaMilliseconds);
The function signatures are exactly the same even though the two classes are not
related in any way. This can be important when you
'
re in a large code base and look-
ing at a class you
ve never seen before. This kind of consistency lets you be reason-
ably sure of what a function does. At Super-Ego Games, all trivial getter functions
started with the word
'
”
It was a simple mechanism that alerted the programmer to a possible performance
hit on what might seem like a simple operation.
You can see a good example of this kind of consistency by looking at the interface for
the STL. Ordered containers use
push_back()
to append an object to the container.
You can be reasonably certain that any ordered container that supports appending
will use a function named
push_back()
. Notice how unordered containers like
std::map
or
std::set
name their function
insert()
. Since these containers
make no guarantees as to which order the objects exist in the container, the behavior
is fundamentally different than it is for ordered containers. This is a good paradigm
to follow in your own code.
Consistency goes beyond naming conventions; it also applies to class layout and code
organization. For example, I prefer to put all of the member variables of a class at the
top, followed by initialization and destruction functions like the constructor and
“
Get,
”
while non-trivial getters started with the word
“
Find.
