Coding standards

[samrussell]

We're getting to the point where we need to put some sort of standards together to help code reviewers and protect the codebase so it's easily extensible.

Open for ideas on this, some general thoughts to get it going:

• Use tests as your rule of thumb - if it's hard to test then the interfaces probably need a rethink
• Test your use cases and name accordingly - you want to test individual paths and edge cases so focus the tests on object_gets_this_and_does_that rather than test_method_name
• Aim for 90% test coverage - the goal of testing is to check your code against your specification, so that needs to be the focus. There will be times where a method or a use case is hard to test, and it's much better to have a caveat and an untested method than a bad test that merely replicates the code.
• Don't mock the system under test - chances are this should be extracted into its own object
• Don't test private methods - if other objects aren't calling this method then you shouldn't be either.
• Don't DRY too early - extending an existing class can often be useful, but it also commits you to an abstraction that might not make sense. 2 copies of code is fine, 3 is a little iffy, and 4 is the point where you should be thinking about extracting a common class and extending from there.
• No more than 5 lines of code per method (a little insane, I expect this to be broken fairly regularly but it should always be with good reason - check out https://robots.thoughtbot.com/sandi-metz-rules-for-developers for some more thought on this)
• Names have meaning - no single-letter variables, no truncating words unnecessarily (recv, msg etc don't save that much typing)