Bug Hunting Safari

Bug Hunting Safari!Janie Clayton-Hasz

Why is Debugging Hard?• We all know we should debug, but many people

don’t know how to do it well.

• Our community does not have an overly broad knowledge base about doing in-depth debugging because it’s hard to make time to learn it better.

• We like to think that we can write all of our code perfectly without any mistakes, but unfortunately that is not the case, no matter how hard we try.

– Crow T. Robot from Mystery Science Theater 3000 for those under the age of thirty or over the age of fifty

“Well, believe me, Mike, I calculated the odds of this succeeding versus

the odds I was doing something incredibly stupid… and I went

ahead anyway…”

Why is Learning Efficient Debugging Important?

• Depending on the source, it is reported that a professional programmer spends only 1/6 of their time coding. Most sources agree that half of your time as a programmer will be spent debugging yours and other people’s code.

• Learning tools, tricks, and common problems will free up more of your time so you can code rather than debug!

Why is Learning Efficient Debugging Important?

• At some point in your career, you will be working on code that you did not write yourself. The previous person will do things differently than you would have and you need to be able to figure out why something you did not write works and breaks.

• You will continue to grow and mature as a developer. Looking at code you did three months ago can be painful and you probably won’t remember what you did or why.

Setting up Your Debugging Environment

Why Have a Debugging Environment??

• Everything you do in work and in life is better when you have a dedicated set-up for it. Look at your kitchen. You have a dedicated space to doing a specific task and everything is arranged to make that as easy as possible

• You have, or should have, a dedicated coding space to help you focus and be productive. If you want to be a productive debugger, you need to care about setting up your space and your tools.

Debugging Console• Create a dedicated debugging tab

• Make sure your bottom view is exposed

• Can set many things to optimize debugging in Xcode\Preferences\Behaviors

NSLog(): First Line of Defense!

NSLog()• NSLog() is a function that you can use to print a

message to your console.

• NSLog() is a development tool. Nothing printed using NSLog() is seen by the user

• Usually used to print out variables to the console in order to check their value and to ensure they are set

• First type of debugging most people learn how to do

Breakpoints!

Thing I accidentally make when I click on an error message that makes my program stop running.

Flavors of Breakpoints• Breakpoint Logging

• Exception Breakpoints

• Conditional Breakpoints

• Symbolic Breakpoints

• Watchpoints

Advantages of Breakpoints• Easier to clear out of production code than NSLog()

statements. You should not include NSLog() statements in an app that is submitted to the App Store

• More flexible than adding code to your project for debugging

• Less likely to generate errors because you are not adding additional code to your project

Breakpoint Logging

Logging with Breakpoints

• Think back to when you were creating all those NSLog() statements. They were kind of messy, weren’t they?

• You can use breakpoints to do the same thing

Exception Breakpoint

When Do You Use an Exception Breakpoint?

• Have you ever built and run your application only to have it crash and direct you to the Main.m file? You know the problem isn’t there because you haven’t touched it. How do you find out where the problem actually is?

• You use an Exception Breakpoint

Exception Breakpoint• What happens with Xcode is that when it

encounters a problem in your code, it will keep going until it crashes. That is why it usually stops in the incredibly unhelpful Main.m class rather than where the problem actually is.

• By creating an exception breakpoint, you are telling Xcode you want it to stop where the problem is rather than to keep going and crash somewhere else.

Conditional Breakpoints

Conditional Breakpoint• You are telling Xcode to stop if a condition is not

met.

• The condition must equate down to a true or a false.

• You can use this in a loop if you need to know what the result of a certain iteration is by setting “Ignore ’n’ times before stopping.”

Watchpoint

Who Watches the Watchpoints?

• Watchpoints are a tool you can use to keep an eye on any object that is going to undergo a change.

• For example, if you have a label that is updated by input from the user, you can set a watchpoint on it.

Symbolic Breakpoint

Symbolic Breakpoints

• Used any time a specific method type is called.

• For example, if you want to know every time the view loads you can create a symbolic breakpoint to do something when viewDidLoad is called.

LLDB: Or How I Stopped Worrying and Learned to Love the

Command Line

What is LLDB?

• All of the tools we have been working with so far are written in LLDB.

• LLDB uses a command line interface.

• Anything you did in Xcode, like setting a breakpoint, can be done on the command line in the debugging console.

Why Would I Want to Know LLDB?

• LLDB has more functionality than what has been built into the user interface in Xcode.

• Writing code in the command line is faster and more efficient than having to use the mouse to move around selecting user interface elements.

• You can do debugging in the terminal and bypass Xcode completely. If you want to use something like AppCode, this is a way to use LLDB.

Why Would I Want to Know LLDB?

• You can customize LLDB commands to suit your projects more closely

• You can extend LLDB’s functionality with the use of Python Scripts

Creative Way to Torture Your Coworkers

Sound Breakpoints!!• You can program a breakpoint to generate a sound

when something happens.

• When you go on vacation, program all of your breakpoints to make annoying sounds when the program is running. Your less knowledgeable coworkers will go crazy figuring out where the sound is coming from!! BWHAHAHA!!!

In Conclusion…

99 little bugs in the code!99 little bugs!

You take one down,You patch it around!

117 little bugs in the code!

Bugs are bad. You do not want bugs. You do not want to ship an app that has bugs. Bugs

are the number one reason that apps are rejected from the App Store.

!

Bugs happen. You don’t want to ignore little bugs…

Because they become BIG BUGS!!

`