Development Guidelines

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.

Code 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 it's 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:
    • CamelCase for classes, underscore_notation for pretty much everything else.
    • The Zen of Python (PEP 20)
    • Style Guide for Python Code (PEP 8) (example)
    • DocString conventions (PEP 257)
  • Javascript:
    • CamelCase for classes, hungarianNotation for 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

Application Guidelines

• Django / URLs? Coming Soon

Git Guidelines

• 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
    - ...
  

Code Review

• Coming Soon

Issue Tracking

• Coming Soon