-
Notifications
You must be signed in to change notification settings - Fork 1
Development Guidelines
nt3rp edited this page Oct 24, 2012
·
19 revisions
Developers spend 3 times more time understanding code than modifying it, and 5 times more time modifying code than writing new code. For this reason, it's important that we make our code as easy to understand as possible by following certain company guidelines.
-
Use spaces, not tabs. Specifically, use 4 spaces instead of a tab.
-
Avoid lines longer than 79 characters
-
When using parenthesis
()or braces{}, use mitred braces. For example:myFunction({ // starts on the same line... //something }); // ...ends on its own line. if (x) { // starts on the same line... //something } else { // ...notice the brace is on the same line here as well. //something } -
Constants tend to be
IN_ALL_CAPS -
Don't leave commented out code in your commit if the code is already in version control:
- Comments are for explanations / design decisions
-
Otherwise, we defer to various language standards:
- Python:
-
CamelCasefor classes,underscore_notationfor pretty much everything else. - The Zen of Python (PEP 20)
- Style Guide for Python Code (PEP 8) (example)
- DocString conventions (PEP 257)
-
- Javascript:
-
CamelCasefor classes,hungarianNotationfor everything else. - Use
"use strict";wherever possible: What does "use strict" do? - Semicolons are not optional
- Use one-line comments (e.g.
//) unless you are writing machine-directives (e.g. JS lint, doxygen, tests) - Douglas Crockford's Javascript Guidelines
-
- Python:
- Database migrations?
- Django / URLs?
-
Avoid commit messages longer than 80 characters
-
Commit messages should generally follow this format:
{Present tense verb} one-liner summarizing the commit - Change 1 - Change 2 - ...
- Pull requests for code reviews follow the same format as git commits
- Code must be reviewed by at least one other person, and ideally including the lead developer
- Coming Soon