Save Time by Taking Time: Check vs. Debug
Introduction
In any world, the first principles define everything that comes after. Everything builds on what has come before, whether it is theology, mathematics, physics, or programming. Making sure your foundation is sure and each level is sound is essential for progress.
It may seem counterproductive, but a coder can save time by taking just a little more time while writing. Everyone has experienced it; there is that moment when you get on a roll and line after line of code comes flowing out onto your keyboard because you have hit some tech nirvana and are one with the code-verse. Suddenly, when you are so proud of the artwork — because let’s not lie, line after line of code is a beautiful thing — on your screen, you run your file and…nothing. Well, not exactly nothing, something worse than nothing, an error!
Everyone has heard that programmers are ‘lazy,’ meaning that they do not like to have more code in the project than is necessary. Ruby has many ways to keep track of your work and check while you code. Additionally, Rubyists don’t want to go back through the code to debug, but who does? It may seem to be a bit counter-intuitive to stop and check with each new piece of code added, but it can not only keep you from making a mistake that cascades down the program and takes more hours to find the bug than the original coding took. That is why Ruby and many other coding languages come with the ability to debug.
There are benefits and drawbacks to each different type of debugging tool that will be talked about below; but first, just a few things to note for any programmer.
Deliverables
First, know your deliverables. This is an absolute must. If you are running through practice labs or working on a project, the first question is, “What does this program need to accomplish?” Then, “What does that look like in code?” If you do not know this, then you will just be floundering in the pool of code, directionless.
Error Types
Second, know how to read errors. It is frustrating to receive an error. However, it is essential to your productivity that any programmer can read through the code and know what it means and where it is pointing to in your code. That will give you the tools to be able to change it correctly.
Using Debugging Tools to Check Your Work
If you know your deliverables and how to read an error, you can logically go into the debugging process. However, the goal of putting in a bit of extra time is that you are saving time and do not have to go back into your code to debug. By using various debugging tools available in Ruby, you can check your code as you go. Two main tools available to a Rubyist are IRB and Pry, a Ruby REPL.
IRB
The first and most basic of these is IRB. IRB is like a new universe each time it is opened.
This can be a handy tool to test out new code. As it is a new universe of code, it has nothing to do with your current code, and you can use trial and error. You can also call methods and verify variables. This can be useful because you can copy and paste your code in and any test information. However, it can become cumbersome to put all of the necessary code into this once you are far into a project. This tool can help early in coding to verify your information and methods. Taking a few minutes and having IRB open in a terminal next to your text editor can help by having realtime results of your initial code as you go by adding any additions to your IRB universe.
PRY
The second tool that can be used is Pry. Making sure that you have [require ‘pry’] at the top of your code you want to run and properly place the binding.pry in your code is a more beneficial way to break into your code during particular methods. This is done by placing the binding.pry inside a specific method to evaluate responses. Like IRB, Pry allows you to add information. You can test methods and add new test code to ensure you receive what you are expecting from your method.
Pry will enter the code at whatever point it is placed. Another valuable alternative to pry is to add it to the run file that you are working with to stop the program and call any aspect of it you would like with any test information you put in. Both of these methods can enable you to check your work as you go.
To spend no more time than is necessary on a project, you should be verifying your work along the way. You could find yourself in a situation where your code runs, there are no errors, but you are not receiving the information that your deliverable is asking for. In that case, it is a grueling task to try to find and fix the bug. If the program was running, then the bug could have had cascading effects upon how you wrote your code because you thought you were getting some particular piece of information that is written in a particular way when you were actually getting information that is written completely differently.
In short, a little time in IRB or Pry to verify your code step by step, no matter how confident you think you are, may end up saving you hours once your code is written and you have to traverse it all over again and rewrite pieces because you did not check your work.
Although, there are more tools that are available to Rubyists, These two are versatile and when used properly can not only stop you from making errors but make you a more efficient coder. Everyone likes an efficient coder.