October 29, 2018
[caption id="" align="aligncenter" width="320"]
When you’re scared to run your code, and it works the first try (Halloween style)![/caption]
When I first started as a developer I ran into some scary scenarios. My code was very error prone and I created some functions that I was expecting a string as the output but I got an object. It was very frustrating and I wasn’t even sure I would be able to understand software development let alone have to go and fix my code. My nightmare scenario was to be hired on as a developer and then have to troubleshoot, a.k.a. debug, some other developers code😱😱😱. I think most junior developers have had shared my fear at some point in their career. I was taught to heavily rely upon outputting your results to the console whether its good or bad to help troubleshoot.
In this post I will do my best to help calm the fears of my fellow junior developers with helpful debugging tools and hopefully transition away from relying upon console.log(). While my focus will be on JavaScript these tools can easily be translated to other languages.
For the longest time console.log() was my go-to when I needed to debug JavaScript code. It was my developer friend who told me what was wrong with my code and was never judgemental . I will admit that there are few scenarios where it is “OK” to output the results of a function to the console.
Except more recently, I have found using console.log() to be less useful when debugging and only making things worse by expecting a good outcome and then disappointing me. Like an expired $5 Amazon Gift Card (Thanks, grandma). Take for example, this gem:
Object doesn't support property or method 'from'
That lovely error is from IE 11 which does not support Array.from(node List) prototype without a shim/poly fill that is available here.
However, I have come to find out that logging errors to the console is either inefficient or completely irrelevant to what may actually be causing the problem in your code. I will admit that some errors are easily resolved by reading the output of the error message and fixing the typo or following the instructions of the error message to help resolve the problem.
So in the image above we are shown a node item which has so many properties that you might not be aware of, which renders console.log useless. You have to know ahead of time what value or specific attribute you are trying to output which requires some abstract thinking or referencing documentation to identify this property. Now using the console.log will output all the entire properties of the node item but its an unnecessary step to add in this line of code while you debug and then go back and remove the line of code.
“You don’t know what you don’t know” -Bill Parcel (Head Coach New England Patriots)
The error the console outputs might provide you with the location of the error, but you may not know why are you getting the error in the first place. Maybe you’re passing the incorrect value to the function or you are working with event handling and bubbling events.
Either way, chances are that you aren’t thinking about that one property that is actually passing the value your expecting because you weren’t aware of how to call it or pass it along.
I’m going to piggy back off of Mozilla’s Debug Playground as an example for why you shouldn’t use the console and instead use the Browsers built-in debugger or equally as helpful is an IDE’s built-in debugger.
cough cough Visual Studio Code cough cough
Now, whether you prefer Chrome over FireFox is a whole different can-o-worms.
“Hey man, I’m a back-end developer and so I need to console.log”
-Fictional Backend Developer
So maybe you don’t have a fully fleshed out web form or you’re trying to get data from some API or JSON file. You need to see data from the function you’re writing or better yet you want to test a function that someone else wrote without having to clone the entire project. Using console.log() seems like the go to. In fact, around ¾ of Node.js developers report using it (in 2017) for finding errors in their applications.
I’m here to tell you of a few better ways to debug your code.
The first tool I have come to love and trust is one made by a company called Wallaby.js
QuokkaJS (Integrated Scratchpad for JavaScript)
With this plug-in you can write your code and get immediate results. No need to throw in a bunch of console.log’s in your function and check the output. It has an integration for VSCode (💖💖💖 ), JetBrainsIDE and Atom. I personally have purchased a pro license but for the most part the community version will work just fine.
SonarLint ( Like spellcheck but for your code)
I think all developers should have some sort of code linting tool added into their IDE. This helps review your code in real-time and “should” prevent you from compiling or running code with errors in it. I’ve chosen SonarLint because its given me better results than ES6 linter or some other linting tools that i’ve tried. I’m not saying its the best or that the others don’t work but I haven’t had to configure much other than just installing the extension.
Scratchpad (Built-in Browser Javascript sandbox)
Mozilla also offers a feature in their DevTools that allows you to write, run, and view the output of JavaScript code that can interact with the current web page or not.
I have a background in .NET development and I have fallen in love with Microsoft’s F# Language along with the fsharp community. While going through the documentation I was introduced to a new term, REPL.
REPL stands for: Read-Evaluate-Print-Loop.
“ In a REPL, the user enters one or more expressions (rather than an entire compilation unit) and the REPL evaluates them and displays the results.” -Wikipedia
So I thought, this was cool and I used my Googliness™️ to search for an online version or service and so I came upon THIS.
I don’t need to console.log my output or assign the function to var result = greeting() and then console.log(greeting("Jessica")) . I just write my function, invoke it and BOOM! I get the output without the need of console.log() .
Repl.it supports many languages!
I can even create a Repl, write some code and share the link with someone that can give me feedback, Brilliant!
Coincidentally, Repl.it uses Monaco, which is the same Editor that VSCode uses.
Finally, for the developer on a budget (including myself) most popular IDEs have a built-in debugger that works the same was as the debugger in Chrome or Firefox.
I've kindly added links to How-Tos: For a few IDEs (don’t get mad if your IDE is not listed, I’m looking at you Atom IDE community).
Debugging in JetBrains IntelliJ
Final Thoughts
So why have I gone through the long winded trouble of explaining / trying to convince you why you should wean yourself off of using the console.log and embrace debugging tools? How was this suppose to make you feel better / more confident in writing code?
The short answer is: I believe having more information and proper tools “should” make coding, and for that matter debugging, less daunting / scary.
Use of widely available, open-source debugging tools is key to be more familiar with software development and to grow as a developer.
[rev_slider alias="footer"][/rev_slider]
Reviews in Switchup & Coursereport as of 2021
