If at first you don’t succeed, pry, pry again.

A deeper look into Pry and debugging

Debugging? What’s that?

My introduction to coding began just a few months ago. I had visited plenty of websites and wanted to learn as much as I possibly could. I spent most of my time learning about Ruby and Javascript, its syntax and how to solve basic problems. When I was done, code was already written to determine if I had completed the challenge correctly, so I clicked a button and moved on when I got it right. Unfortunately this completely overlooks the whole process of debugging and it doesn’t teach you how to go about fixing your problems as you move along through your code.

I am currently about to enter my third week at the Flatiron School for programming and the importance of debugging has already been stressed multiple times. Last week I attended a seminar with Flatiron graduates and I was surprised to hear that one of them had gotten a job because of her ability to debug. She said that Flatiron had taught her how to debug effectively and that made her stand out against many of the others that were also competing for the same job as her. You mean they didn’t debug?

Her comment about debugging made me want to take a deeper look in to the process of debugging. It has become somewhat of a running joke in my cohort that the first thing you do when creating something new is to require ‘pry’. Pry has been my introduction to debugging in Ruby and is a REPL (read-eval- print loop) tool that allows the user to create and test code. It is similar to the default ruby REPL, IRB(Interactive Ruby).

Pry has many advanced features that IRB does not though. Pry allows the user to place a REPL within the code being created so that it can be tested with past code. Where ever you place the pry, is where the code is going to stop running. It should be stated that it can be used just like IRB though, and can be ran just by simply typing in pry. I personally have been using it within the methods I create and and it has been particularly useful inside the block when trying to figure out where I’m at, especially when I’m dealing with nested hashes and arrays. It has been an extremely useful tool in both understanding and fixing code that I create.

Another great feature of Pry that I was unaware of was that you can use certain terminal functions such as ‘cd’ within the code to test things such as instance methods and classes as ‘self’. You don’t need to call on the class or the instance. You simply ‘cd’ into an instance or class and call those methods on self. You can also ‘ls’ to see a list of what is available to whatever it is that you are within. Commands such as -g, -c, -l, -i, -m and -M can show the user the global, constant, local, and instance variables as well methods and instance methods, respectively. If you’re wondering where you are after you’ve cd’d into multiple things, you can use the nesting command which will inform you where you are currently at.

Some of the many other useful commands are edit, in groups, and show source. The edit command allows the user to simply type ‘edit’ and the name of the method you are working on. This will open your text editor and bring you right to the method you want to work on. The ‘in groups’ of method will organize what you are looking for into groups of the size you tell it, which can make looking through lots of methods or variables more manageable. One of my new favorites, calling ‘show-source’ before something will actually reveal that objects original source code! Finally, a convenient feature is that a user can put a dot in front of terminal commands to act outside of the pry.

Although pry seems to be the preferred debugging tool for Ruby, there are plenty of others out there. A quick search shows the many debugging tools available, Fir and Byebug to name a few. Whichever one you choose to use, it’s easy to see why every one would should incorporate these tools into their workflow.