Be Obsessive with Your Code Style

Tony Coconate

Tony Coconate

We often disregard style as part of beautiful code, but standardizing your coding style can make life in the development world much easier.


My apartment is super clean.

O.C.D. is A-Okay

I cannot stress enough that being an obsessive and compulsive person will lead to better, more readable code. Force others on your teams to become as crazy as you are. They might hate you but you will sleep better. Passionate people drive to make great things possible (See: Steve Jobs). Dispassionate people usually equate passion to things like working late or nitpicking.

That is not the case.

I mean... sometimes it is, but for the point of this blog it's not, so chill out, okay?

Being nuts up front can save hours of untangling in the long run. Well structured and disciplined codebases are easy to jump into and be productive. Adding team members is easier. Refactors become fun and an exercise in strengthening your skills.

Police Your Codebase

Be a jerk.

Are people committing after hours or pushing unreviewed code to master?

Revert their commits.

Be a cop. Be the best kind of bad guy.

If you have the power of committing, enforce it. Master should not be some playground for features that are half-baked and thought about away from the rest of the team.

Nobody can hide in codebases I'm a part of. I'll find you. I swear I will. And, if I see you doing some weird stuff, I'll be critical. I'll also find ways to be as constructive as I can.

I'm not talking about openly bashing that junior developer your team just hired. I'm talking about enforcing a quality of deliverables. If it's not up to par, get it there. Pair with the guilty party and level them up. Show the team you are willing to take their side and willing to lend your expertise. You're the guilty party? Reach for help. Nothing moves people up the chain of command more than humility.


I know time can slip from us all. That doesn't mean that you can leave the bad stuff alone. Go back to it. Don't bury those little nuggets. Dig them up as soon as you can and toss them away.

Don't make the race the excuse. Take pride in good software decisions and push back on the flood gates. If they don't stop, find time between the infinite Facebook and Twitter peeks you make daily to say to yourself, "Self, am I really being rushed to the finish line, or is it just that I'm letting myself obsess over what @tonycoco's stream is doing?".

Take a Good Look At Yourself

Have a look at this "sample" (some class and method names have been changed for anonymity)...

class Something
  def hello string = "world"
    # Just putting a string here!
    puts string + "#{1 +3 - 4   + 6}"

    #this method does nothing
    def nothing_to_see_here(optionsHash={})

  # TODO: Write tests

  #FIXME awe man, I should have written tests, son.


How are people checking in this garbage? Seriously? Come on.

My head almost exploded. Sure, it may "work" but it is in dire need of a style guide. Get one together and stick to it.

Try this on for size...

class Something
  def hello(string="world")
    puts string + "#{1 + 3 - 4 + 6}"


  def nothing_to_see_here(options={})

Did you notice the comments? They're dead. Comments don't exist. Never leave a love note to the next developer because you couldn't figure out how to be succinct and concise. Nobody wants to read your poorly formatted, cute shoutout to yourself.

I've been following GitHub's for quite some time now. Consistency breeds success in almost every aspect of life. Your codebase should be personality-less. If another team member breezes over your code it should be indistinguishable from their own.


Of course, there are exceptions. RDoc or YARD are totally fine, but if we are talking to each other in codebases we probably need a therapist before we need a TODO list...

The Fabled TODO List

Also, TODO's are terrible ideas inside the confines of your codebase. If you have something TODO, pull out your hot new pair of Nikes and just do it. If it's truly a task that you can't imagine getting to "right now", put it in a task-management system separate from the codebase. I like Trello... for now.

Either way, make it a task that can be allotted time to be worked on. This is not a thrown away New Year's resolution list stuck to the back of your refrigerator with a number of bullet points, one saying, "Pay Student Loans Off". This is real stuff you probably mean to actually do one day.

Boiler Lining Playbook

Get a project boilerplate. I'm not talking about a Rails template. Instead, standardize how you test. Your factories, validations and associations should be tested. Come up with a basic stockpile of all things "boilerplate" and have tests for them. It should help drive a good base for your code.

I keep a Gist of what I call The Greatest Hits of Rspec Testing: Volume 1. You can rip it here. It's a cheat sheet of sorts. The main point here is that you need a place to keep a list of specifications you'll almost alway lean on. I constantly find myself going to the shoulda-matchers for the validation specs, Relish's site and a few other resources on a daily basis.

Don't reinvent the wheel. Try to stay as far from the "Not Made Here" fear that kills most Clojure web frameworks. Utilize the community's resources. They are abundant in Rubyland.


This is probably the easiest thing you can get big wins on straight away. For instance, your stylesheets should be organized in a sane manner...

|-- screen/
|   |-- _fonts.css.scss
|   |-- _homepage.css.scss
|   |-- _mixins.css.scss
|   |-- _overrides.css.scss
|   |-- _pages.css.scss
|   |-- _shared.css.scss
|   |-- _variables.css.scss
|   |-- all.css.scss
|-- application.css

Now, your application.css file looks like...

 *= require screen/all

And, your screen/all.css.scss file looks like this...

@import "normalize";
@import "bourbon";
@import "overrides";
@import "neat";
@import "mixins";
@import "fonts";
@import "shared";
@import "homepage";
@import "pages";

Keep it super simple. Modularize.

And, it doesn't stop at file structure. Code structure too.

Let's take this sample ActiveRecord class...

class Resource < ActiveRecord::Base
  include Commentable

  EXAMPLE_CONSTANT_VALUE = "Make it easy to find a class' constants."

  scope :example_scope, -> { where(example_attribute: "example") }

  before_validation :example_callback

  validates :example_attribute, presence: true

  def self.example_class_method; end

  def initialize; end

  def example_method; end


  def example_private_method; end

Laying out the structure of where class methods and instance methods go makes it easier for the next developer to pick up right where you leave off. It makes me smile. We sometimes go so far as to alphabetically order the methods in their respective "sections".


Here's a list of tools I use...

Everything south of Sublime Text 3 can be installed from the Package Manager. Some of the linters are dependent on gems or binaries that get installed as prerequisites. Follow the documentation closely.

If Sublime is not your cup of tea, that's cool. Most of these tools can be found within the ecosystems of their 1977 counterparts (VIM or Emacs). If I get stuck on a terminal from the 80's I'll be sure to call you all for the 10 keystroke combos I'm so sadly missing out on.

If you take away one thing from this post it is this: Get a linter. Now.

Like, bookmark this page and get a linter or I'll just flip out. Come back when you're done.

Actually, you could have just left because that basically concludes this blog post. I'll be sure to update the tools section if I change my mind about any of them. Which bring me to my next point...

Open Opinions

My opinion of things, software or otherwise, are constantly challenged by co-workers on a bi-hourly basis. It's borderline maddening. I consider myself a fairly harsh critic, but I'm also willing to shed my pride if a well enough point is made to me. Opinions matter to us all so carry yours and be ready to defend it.

Don't like double-quoted strings? I can give you three reasons right away that enforcing single-quoted strings should not be in a style guide...

  1. You can't immediately interpolate. ('#{some_variable}' vs. "#{some_variable}")
  2. You can't say words like can't. ('can't' vs. "can't")
  3. There is almost no performance gain.

Having an open, strong opinion can lead to people looking to challenge it. Which, guess what, is great. Discussion and knowledge are the best weapons and can only spread a wealth of good things in your life, workplace and codebases.

Want to work with us?