There aren’t too many things that bring me down when I’m deep into programming. But there’s always one thing that’ll stop me dead in my tracks: a code smell. In the context of programming, a code smell is something that tells you that your code is…well, a bit off.
Whether you’ve been programming for months or for decades, you’ll run into “code that smells” again and again. Except the better that you get, you’ll anticipate your code smelling, or before you even write it, you’ll know that it’s going to stink. For me, a lot of my code that tends to smell are sections where I’ve duplicated what I’ve written, which is to say that I’ve written something that’s identical or at least very, very similar to another piece of code in my application. I’ve noticed that I’ve started catching myself as I write duplicated code, which is a sign that I’m getting better as a developer – hooray!
But, there are a lot of common code smells, and I definitely still can’t catch all of them in my own code. Generally, if any part of your program has a common code smell, it’s a sign that you need to rethink how your system is structured on a deeper level, and that it’s probably time to start refactoring.
Recently, I’ve noticed that I’ve been sniffing out the same issue in my code: long methods. So I did a bit of investigating and found that there are some cool ways to shorten up your longer methods. Thanks to Ruby magic, we have easy access to methods like
to_proc in the form of “ampersand and object”, or the &: syntax. If you have no clue what those are, don’t worry. I didn’t either! Until I wrote this post, obvs.