“Debugger” Statement Makes Javascript Development Easier

JavaScript debugging is challenging when using script loading libraries like Require.JS, or Lab.JS. These are the sorts of libraries implementing the Asynchronous Module Dependency (AMD) pattern demand-loading source code at run-time when referenced.

AMD is a fantastic optimization technique as it minimizes code loaded, compiled, and stored in RAM. With the benefit comes setting break-points at the start of an app debugging cycle tricky (impossible?). After all, some of the code you want to focus on might not be resident to start.

What is AMD

Here are some references for AMD that serves as for background on this growing important topic:

Help for Debugging AMD Enables Apps

Our favorite language has a big help for the tricky scenario written about above. It’s the “debugger” keyword. Inexplicably it’s hardly mentioned in typical programming texts, or even uttered by fellow coders as a handy tool in the ole developer toolbox. I’m using this space to tell you I love the “debugger” keyword and I hope you grow fond of it too!

What Exactly Does It Do?

Why am I writing about this statement and what does it do? It simply signals the debugger. In the case of the awesome Google Chrome developer tools it triggers a program-execution break. Chrome sees the line and dumps you into its source code debugger. Then we may inspect variables, observe the call stack, single-step code, and all that good stuff. It’s especially useful for troublesome routines under development.

Aren’t Breakpoints Preserved?

Generally speaking break-points are retained between development sessions, but those are based on line-count and lines of code easily shift around while you rapidly spin on the edit-run-debug cycle. Shifting break-points are almost counter-useful at some point.

Debugger statements always sit dutifully where placed. Patiently waiting for run precisely where most desired. Fantastic!

Code Example

Honestly it couldn’t be easier to use this statement, but here’s a code example just because code is totally rad.



    function buildPolygon(x1, y1, x2, y2, x3, y3, x4, y4, id, color) {
      debugger;
      var html = '';
      return html;
    }

JSLint vs Debugger: Fight!

When you’re using a code-quality tool such as JSLint its rules more than likely flag “debugger” statements as an error. Given that be sure to remove them before pushing your code to git. Especially if your Jenkins build-server automatically pours fresh code through JSLint as part of its testing and validation path. Not to mention these things make a stumbling stone for your teammates to trip over. Let’s clean up the debug spam when we’re done, eh.

Does this Make Things Easier?

Will using this simple statement make development easier? Absolutely! Debugging fresh baked code is some of the toughest stuff we do as programmers. We never get an interesting routine correct on the first go. Of course we all know legacy code seemingly deteriorates over time given new inputs. Shifting circumstances beneath us doesn’t make it any easier fixing troublesome logic. Forgetting to tweak breakpoints before running code is a total waste of time once a bug’s repro steps are followed.

Use the “debugger” statement. Make your code more reliable and functional. Have a coffee and do something awesome today!

You may enjoy my book if you learned from this article. It’s called Responsive Web Design Toolkit: Hammering Websites Into Shape. Get it on Amazon today!