Skip to content

My Coding Styles

by Topper on January 24th, 2012

I’ve already written about my path-to-pretty coding style. However, I have not written more specifically about how I approach each language in my rails stack. I do realize some of what I’ll say below is not best-practice. This is my pragmatic approach to how I code, YMMV. I have tended to work at medium scale (1-3mm user) sites handling medium traffic (2-300 req/sec) with a small number of employees (6-50). At an order of magnitude larger of any of those statistics I realize you have to tighten up.

Ruby

  • 2 space tabs (no tabs)
  • wrap 3rd party APIs whenever you’re using them a lot
  • use modules to namespace gems with many classes
  • try my best to rely on 3rd party code, contribute back when broke
  • edge cases aren’t edge cases at scale – they happen. Think about them.
  • anything intended for the greater world must be specced to perfection, anything used internally must at the very least have enough specs that I cannot typo anything.
  • Interaction with 3rd party APIs are hard to spec which is why it’s better to wrap in your own classes. Initial testing can hit the live API, and then you can move off of doing that.

Rails

  • always REST, write controllers as if they were an API
  • controllers shouldn’t do much
  • models can get kind of thick. Break out into modules when *too* thick, but play that loose.
  • classes wrapping models (especially for your REST api) are encouraged and dropped right in the models folder. Model != Db table.
  • Rails 3.1+ asset management is a gift. Use it. Pass config from backend to front end using erb.
  • Your models should be very well specced. Your controllers really only need a surface layer. Acceptance tests are awesome to have when you get there.

JavaScript

  • CoffeeScript is better
  • jQuery is a gift. Use it.
  • namespace everything – global functions do not belong
  • any custom code you use belongs in your own namespace at Motionbox we used MBX.blah
  • I tend to believe that changing prototypes is OK, but I recognize the why of “don’t” and so don’t do it myself. I don’t avoid libraries just because they change prototypes.
  • Use an MVC framework (even for little things).
  • Spec out the MVC models. I rely on the acceptance tests for the V and C code (mostly). Any tests that rely on HTML can be brittle.

CSS/HTML

  • namespace all your CSS under one global class (you’ll thank me later)
  • never use style words in your classes or IDs. HTML is supposed to be what a document IS not what a document looks like. If something is a submit button it’s a “submit-button” not a “blue-submit-button.”
  • Use the minimum amount of HTML to have your app look right. Play with it, don’t just git ‘er done.
  • HTML should at least look like it’s functional (forms should point at the right place and be submittable). However, I’m not a zealot when it comes to progressive javascript enhancement. My target audience probably has Javascript enabled. Yours may not… think about your audience.

From → Social Web