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

You don't need to log nor guess—you can actually see when, where, and why the value
changed.

Setting breakpoints and stepping over code are as fundamental to debugging as NSLog
statements are. The two go hand in hand, with NSLog being most suitable in cases where
breakpoints would otherwise trigger so often or interfere with user input that a given issue
can't be reproduced. Breakpoints and single-stepping through your code are extremely in-
structive, as you can literally see what paths your code is taking and, through the Variables
View, you can also see why.

The question for you then becomes one of figuring out why a given value doesn't have the
value it's supposed to have. But you can quickly arrive at that point by using breakpoints,
rather than making changes to your code based on guesses and then trying again, hoping it
might work the next time.

Analyzing Your Code

A lesser known feature of Xcode are the so-called analyze builds. You can run an analyze
build via Product

Analyze . This runs the Clang Static Analyzer tool that ships with

Xcode.
The analysis tries to find common, known, and potential sources of bugs. This includes
memory management and logic errors. However, not all issues reported by the analyzer
need to be actual problems. For one, any issue found in code not written by you, such as
the Cocos2D and Chipmunk sources, need to be disregarded. Assume that if they are actu-
al problems the developers will eventually fix them.
Figure 14-10 shows the output of an Analyze build. The 12 issues found in the Cocos2d
target can be ignored. There's only one issue in the LearnSpriteBuilder project, and a sug-
gestion is made to fix it.