This repository has been archived by the owner on Mar 14, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 18
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.
- Use Weirich style blocks - if the return value is important, use curlies, if not, use
do..end
. - Use
Hash[]
overinject({})
- 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 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
).
- it's OK for a RESTful route to be backed by a meaningful method name (e.g.
- Remember that most requests to the controller layer are JSON. Handle errors appropriately
- 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 theRedis
orResqueInstance
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.
- 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 ofassert !
and friends - In model tests, avoid requiring Rails. Use
quick_test_helper
and the providedrails_require
andlib_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.
- 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
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
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.
- 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