Skip to content
This repository has been archived by the owner on Mar 14, 2019. It is now read-only.

Coding Conventions

David Copeland edited this page Jun 8, 2014 · 2 revisions

I'd like to keep this consistent with the style that's in use.

Rails/Ruby

General

  • Use Weirich style blocks - if the return value is important, use curlies, if not, use do..end.
  • Use Hash[] over inject({})
  • Variable names should be English words and readable. Use vowels and avoid abbreviations
  • Chain collection transformations and avoid intermediate variables
  • Avoid nil if you can
  • Use parens for all methods that aren't Rails-provided DSL methods.
  • Use JSON style for Hashes with symbols for keys
  • RDoc all public methods, including parameters, option hash keys, and return value
  • I use pretty aggressive code typography. Please see that you do the same.

Controllers

  • Controllers should do very little. Figure out the params and defer to something else.
  • Routes should be RESTful, with the following caveats:
    • it's OK for a RESTful route to be backed by a meaningful method name (e.g. JobsController#running).
    • POST to an endpoint for RPC-style calls (e.g. FailedJobsController#retry).
  • Remember that most requests to the controller layer are JSON. Handle errors appropriately

Models et. al.

  • Models should avoid configuring their dependencies, preferring to accept fully-formed instances to their constructors
  • Dependency configuration should be done in factory methods. See Resques::from_environment as an example—objects of that class have no direct dependencies on the Redis or ResqueInstance classes.
  • For "record"-style objects, please accept a Hash of values in the constructor (see e.g. Job) instead of big vomit of positional parameters.
  • Do not provide setter methods or other ways to mutate object instance internal state, preferring an immutable style.

Tests

  • Try to avoid introducing a mocking or stubbing framework.
  • test methods should assert all behavior of the call under test. Do not make 10 tests with the same setup and method call to assert the 10 effects of that call.
  • Use refute and friends instead of assert ! and friends
  • In model tests, avoid requiring Rails. Use quick_test_helper and the provided rails_require and lib_require.
  • Controller tests assert the format of the JSON being exposed to the front-end.
  • Major features should have integration tests, as should any complex UI.

CoffeeScript

General

  • Use parens. Do not waste time trying to write the code without them
  • Use camelCase
  • Create object literals multi-line with no commas
  • Do not make classes
  • Do not use JQuery
  • Do not write code that relies on the value of this
  • Use LoDash's collection functions to avoid intermediate variables

AngularJS

Although I've created several Angular apps, I have done so in a vacuum, so it's possible my "accent" in Angular is really weird. Would love feedback on this. In general, this is how I've written the Angular stuff:

  • Controllers contain all needed state and exposed functions
  • Anything not controller-specific goes in a service
  • All HTTP traffic gets wrapped in a service
  • Use $resource everywhere possible to interact with the backend
  • Never ignore an error
  • Use directives for sharing markup as well as for, well, directives

Tests

Again, my Angular tests might be really weird. There's a ton of boilerplate in them that drives me bananas, so if you can help me understand how to reduce that, it would be appreciated.

CSS

  • Try not to write any CSS and use Bootstrap's CSS
  • If what you need to do can be done by creating a generic class, do it that way, e.g. .mt-1 is for creating a margin top of "1 unit".
  • If what you need to do is not re-usable and for a specific view, do not make a zillion single-purpose classes, just make one that does what you need (e.g. .failed-job).
  • Use px
  • Make it look nice