Tag Archives: debug

Stop Using Print and Die Statements

July 1st, 2019
min read

Today we are going to go over debugging 101 tips for using print or die statements. Discussing what you should do & why. The tips presented here are suitable for devs of all skill levels. Simply follow the instructions below to get your code on.

The Traditional Way

The statements below exist in every language & we all rely on them to #debug at some point.

Ruby:


puts "Message goes here"
exit

PHP:


print_f("Message goes here")
die();

Javascript:


console.log("Message goes here");
fail;

You Get the Point Instead of the above, try using purpose built debugging tools. Believe it or not, using tools can make you a better programmer. A senior engineer once told me (early in my career) that anyone who doesn’t use a debugger is a chump. I could not agree more.

Seeing the Entire Picture

For those who are unfamiliar with debuggers, here is a quick introduction.

Debuggers stop a program mid execution, show the state of it & allow you to take a deep dive in.

Code being stepped through with debugger.
A PHP script stopped mid execution using a debugger.

A debugger also allows you to step through your code, so you can see what is happening live.

Code being stepped through with debugger two lines down.
A PHP script stepped down two lines in the same method.

Without this tool, seeing the entire picture of a program is next to impossible (if I am wrong about that, please show me a different way).

A debugger also allows you to check all current variable values at a specific point in execution. Globals, local variables, even variables buried deep in a private method. You can see it all.

A list of variables shown in the debugger.
A look at all variables in the current execution context.
A variable object extended.
An in depth look at the “$request” variable.
Anyone who doesn’t use a debugger is a chump. – Cam Stew

Debuggers also show you the call stack leading up to that point of execution. Some even let you jump around in the stack. It shows the file, and method that was executed.

A call stack shown in the debugger.
A call stack shown by the debugger.

Engage with It

Not only can you take a look, but you can manipulate as well. Change the value of anything and execute the program based on the values that you have chosen at that time. The power that comes with this can be wonderful. For instance, you want to assure that your data being fed into the method is correct, you can change what is incorrect just to test if your code does what you expect. This is a double edge sword though, the rest of the program executes on the data that you changed. Be careful.

Gain a Deep Understanding

By stepping into the code, you automatically make the source code of whatever framework/library you are working with relatable. You are able to visably see the code change your data. This helps gain a deep understanding of system control flow, especially when using a third party library or framework. I think one of the best ways to learn a framework is to dive into the source. A debugger forces that.

Underwater turtle diving
Dive into the source

Up Next

My next article in this series will be a closer look at the finer details of a #debugger. So today I want to leave you with one action item that you can start to implement using Javascript.

debugger;


function someThing(test) {
  test.er = 'howdy';
  debugger;
  test.ing();
}

This keyword in #Javascript allows you to fire a debugger automatically when executed in Chrome or Firefox. Note that you must have your console open in order for the debugger to stop execution. Then you can step through and into methods as needed. No more console.log();

Use it. Get comfortable with it. It works.