Debugging & Best Practices - Learn SpriteBuilder for iOS Game Development - page 483

aspect of programming. Both writing and debugging code can be learned through exer-
cise. To write code, you need to learn the programming language, and to write better code
you need to learn about code design and architecture. The same goes for debugging,
where you need to learn the tools used to debug an application. Eventually, you'll learn
about strategies for avoiding issues and catching them early, as well as classifying bugs
and picking the right tools for analyzing them.
This advice is just scratching the surface of measures you can try, and it's rather general-
ized. But I do hope it puts you in the right state of mind: bugs are challenging you to over-
come them. And every time you succeed, you become a better programmer, and you'll
continue to succeed more often and more quickly because of it. Plus, it can be a very up-
lifting feeling to fix that pesky bastard of a bug that's been bothering you on and off.
Frequently Encountered Issues
While writing the topic, I myself came across many issues that can be attributed to human
error or misunderstandings about the SpriteBuilder interface. Some issues surfaced rather
frequently, so I would like to summarize them here.
Nil References
A common problem is realizing that an ivar or property is nil . This condition is easy to
find out with a breakpoint or NSLog . But why is it nil ?
If you assign the variable via SpriteBuilder's Item Code Connections tab, check the fol-
lowing:
Whether the variable type is set to “doc root var.”
Whether there is a misunderstanding, such as the doc root var is assigned to
the CCB root node's Custom class, rather than the Custom class of the
node.
Whether the CCB's root node has its Custom class field set to the correct
class.
Whether the custom class in question has declared a corresponding ivar or
property of the same name.