Ruby is an expressive and beautiful programming language. Ruby code is supposed to be readable enough that if you gave a non-programmer read basic lines, they’d be able to figure out what was happening. Having readable code will benefit you not only today, but when you might need to look back and try to make heads or tails of the code you wrote months or even years ago. Just as important, those you collaborate with and others who look at your code won’t curse your name under their breath as they read it. Unfortunately, as a noob, I repeatedly found ways to mangle and uglify my code. Don’t be me. Here are a few tips to make your code look, read and perform better.

1) Spacing: two (indent), one (commas, colons, semicolons and “{}”) and none (“()”, “[]”). Indenting lines with spaces and aligning blocks of code that belong together creates a structure similar to searching through folders and directories. It makes it easier to follow the logic and for others to read your code. Don’t use the hard tab button UNLESS you’ve changed the functionality of the tab button to just add 2 spaces automatically. For instance, Sublime (text editor) allows you to set the “indent” (pressing tab) to actually generate two spaces instead of a hard tab.

2) Comments: less is more.There is a fine line between overcommenting and undercommenting. Your code should be expressive enough that you shouldn’t need to comment how it works. If it’s not, that’s a reason to refactor the actual code rather than comment more. Get rid of old comments, pseudo-code or old commented-out snippets. So when to comment? How to use your code and some code author/creator information are good reasons to comment. When in doubt, err on the side of brevity.

3) 80 character limit and aligning parameters. Long lines are hard to read, and cumbersome if you have to scroll horizontally to read them. Keep your lines short < 80 characters. If you have a lengthy parameter/argument list, separate them and align them. You want your reader to read your code from top-to-bottom, not left-to-right.

4) Naming: variables and methods, Classes and Modules, CONSTANTS. Variables and methods should be lowercase, Classes and Modules should be CamelCase and constants should be all-caps. Don’t use variable or method names on the ruby keywords list. That’s a recipe for disaster and confusion.

5) Be concise and DRY. Don’t Repeat Yourself is a dictum of the Ruby programming language. If you see yourself writing the same lines of code over and over, you can probably encapsulate the logic into a single method. Similarly, don’t write in 3 lines of code what you could write in one. Starting out, my initial goal was to just get my program working. Then, I would reread the code and refactor to make it more concise and reduce redundancies. The more code I write and reread, the more patterns I see, allowing me to refactor on the fly rather than waiting till the end.

Use common sense. You want the code to be consistent, organized, concise and self-explantory. For more on Ruby style, syntax and conventions, I highly recommend this Ruby Style guide.

Who am I? Man’s age old question is the same one I’ve been asking myself in Ruby over the last few days. The key word self is the embodiment of the question, with a slight twist. In Ruby, everything is an object, and there is one and only one current object at a given point. This current object is self. Depending on where you are in the program, self will be different. Here are some examples to illustrate how self changes depending on the context of the situation.

Context 1: Top-Level

Main is the default top level object that self refers to, and main itself is an instance of an object. Self in top level methods reference whatever object the method is being called on.

Context 2: Classes/Modules

Here, self is the Class or Module object.

So, we’ve seen self go from top-level main to individual Classes and Modules.

Context 3: Instance and Class Methods

The key here is that a method is telling an object what to do, so self within a method is always the object on which the method is being called on (the receiver of the message). When we first created the instance of the Class Rapper (ice_cube = Rapper.new), and subsequently called time_period on that instance, self is referencing that specific instance, and denotes it by the #Rapper:0x bunch of digits, which is the memory location of that instance. We see that when we call the consensus method on that instance, we get the same object (self) confirmed by the same reference number. However, if we look at the class method self.consensus, the object in self is the class Rapper. Of note, defining the method as self.consensus would have been equivalent to writing Rapper.consensus, which underscores that Rapper = self. In summary, self can be representing the Class object or an instance of the Class object depending on the context.

For further reading, check it yo:
Jimmy Cuadra: Self in Ruby
Sid’s Weblog: What Exactly is Ruby Self
Paul Barry: Rules of Ruby Self

And last but not least, here’s Ice Cube’s words of wisdom on the subject…

Last week, I started as a student at the Flatiron School, a 3-month, full-time, web development program here in NYC. Why?

1. Build something. “I wish someone would create something that would fix problem xyz” - a commong refrain heard amongst my friend circles. I’m tired of saying that, tired of building sand castles in the sky and always waiting for someone else to take action. I want to turn ideas into reality. If you can think it, you can code it.

2. Don’t be left behind. As Marc Andreesen’s alludes to in his piece Why Software is Eating the World, we are becoming a more technology - and specifically, software - dependent society on a daily basis. A unfortunate by-product is the chasm developing between those who have the aptitude to be part of the transformation and those whose skills are fast becoming antiquated. Being able to code on even a rudimentary basis will be a new form of literacy, as basic as reading or writing.

3. Never stop learning. My programming acumen prior to starting school was non-existent. So after developing a skillset in a completely different field, why would I put myself in a situation where I’m starting from scratch? I think learning for learning’s sake is intellectually stimulating and expand’s one horizons. I don’t know what the end result of these 3 months will be, but I’ve already learned a ton which has already made the experience worth it.

4. Creative outlet. Sadly, I have no artistic talent. I can’t draw, and despite what you may have heard about my amazing “Livin’ on a Prayer” Karaoke rendition, I can’t sing either. I look at coding as a means of expressing myself creatively.

5. It’s fun. Psychologists refer to flow as a mental state where you’re fully immersed in an activity, an almost spiritutual state where you lose track of time. I have the attention span of a 5-year old, and while I’ve only been doing this for a week, I’m finding myself spending hours on coding exercises and not realizing how much time I’m spending. And despite that, I’m still enjoying myself. I get a kick out of breaking down and solving problems, and there are very few feelings like the moment when something clicks. I like having those moments. I want more.

This is the start of something big.