Coding Standards

Coding Standards

USE GIT

We don't just use git to make your life more complicated. It serves a really important function of allowing us to quickly and effectively manage our versions and confidently add new code and features without fear of breaking the entire site! (We can always rollback if one commit does something bad). So in order to take full advantage of the wonderfulness that is Git, here are some basic guidelines:

• ABB (Always Be Branching):

  master is our production branch and therefore you should not be working directly on it ever. Instead make a branch off of master (git branch -b <branch_name_here>) and work there. When your code is ready to be added to the production code base, submit a pull request using github's pull request feature so that another developer can review the code and give it the A-OK to be merged in. It is also recommended to name your branches in the following manner: <your initials>-<description_of_feature/bug_fix>. This way it is easy to keep track of what branch does what (and who is the main author).

• Commits are Friends, Not Food:

  Get in the habit of committing often and for small changes. It may seem like a hassle, but doing this allows you to not only go back to a specific change if you need to, but it also allows us to have a detailed history of all the changes done to the code base. This way if anything goes wrong in the future, we can look through the commits to see what might have caused it. We all break stuff sometimes and it helps to have a good account of where it happened.

• "AAAAYYY LMAO/asdfasdfasdf/did stuff":

  Just as commits are super useful, so are their corresponding messages. Don't just throw in some random string or non descriptive statement into the message. Be descriptive (and concise) about what exactly this commit did. Instead of "made css changes", how about "changed nav-bar styles". I know this can be hard for larger commits (but that's why you should be committing more often!!), but doing the best you can here can really help down the road and makes our code base that much easier to maintain.

###Coding Style One of the nice things about using rails is that between Ruby, CoffeeScript, and SCSS we can maintain a similar coding style no matter what type of file we're working on. (Especially between Ruby and CoffeeScript which share a lot of the same syntaxes)

• Indentation: We use 2 spaces for indentation for all our code. Most text editors allow you to specify how many spaces you want your indentations to be and even convert tabs to spaces upon saving the file. Sticking to this standard helps maintain code readability (especially on github which gets wonky with tabs...) and helps keep things sane as we pass the code between different developers.

• Line Length: Lines should be less than 100 characters long, with a hard limit at 120.

• Code Blocks: Instead of trying to explain, here are a few examples in ruby and sass ->

    if (condition)
      #code in here
    elif (another_condition)
      #different code here
    else
      #even more different code here
    end
  
    def function_name(argument1, argument2)
      #I'm a really cool function
    end
  
    .awesome-class {
      position: everywhere;
      color: ultraviolet;
    
      &.even-more-awesome {
        font-weight: yes;
      }
    }
  

Simple stuff.

Variable Names

Just for consistencies sake we use underscores_for_ruby variables and lowerCamelCase for CoffeeScript Variables. NOTE: There is one little gotcha when it comes to working with rails variables (especially those resulting from ActiveRecord calls which is pluralization. Be very careful that variable names match up with the plurality of related ActiveRecord object. This will avoid a lot of headaches.

Controllers

Index, Show, New, Create, Edit, Update, Delete, Parameters, and a handful of small functions are all that should reside in a controller. If you find yourself adding a lot of code to a controller it can probably be moved to either a component or the model itself (depending on what the code does). We try to keep lean controllers.

DRY Coding

Like my sense of humor I like to keep my code dry. This is just one of those "duh" things that probably doesn't need to be said, but is still very important. DON'T REPEAT YOURSELF. DON'T REPEAT YOURSELF.