Style Guide

General guidelines

1. Keep lines <=120 characters long whenever it doesn't negatively impact readability.
2. Comments should start with a space and a capital letter, and they should end with a period.

   // This is the correct style.
   //this is incorrect
   

3. Use spaces instead of tabs.
4. End all files with a newline character. You can tell if you did not by looking at your PR on Github.
5. Spacing conventions:
   • DO include a space:
     1. Before any open {
     2. Between keywords such as if or for and an open (
     3. Before and after operators like +, &&, or ==
   • DO NOT include a space:
     1. Between a function name and an open (
   • Here is some example code with the correct conventions:

     function doSomething(param) {
         if (param === "firstOption") {
             doSomethingElse();
         } else {
             doSomethingElseElse();
         }
     }
     

6. Commit messages on Github should be descriptive. Say what change you actually made to the code. Here are some common commit messages people make that are not descriptive enough:
   • Fixes #880
   • Addresses feedback from PR
   • Update ModalMissionComplete.js

HTML/CSS guidelines

1. Styling should almost always be done in CSS files, not directly in the HTML. Though there are some cases where styling is dynamically changed using JavaScript.
2. Unlike most of your code, do not include spaces around = in HTML.

JavaScript guidelines

1. If you are adding new JavaScript files, try to use ECMA6 instead of ECMA5. However, most of our code was written using ECMA5, and if you are editing a file that is entirely written using ECMA5, keep with that standard in your edits.
2. For consistency, try to use single quotes (') for string literals instead of double quotes ("). Of course, backticks (`) allow for string interpolation and multi-line strings, so if those features are useful for a given string, definitely use those.
3. If you are declaring multiple variables, add a var on each line:

   var do;
   var this;
   

   var not,
       this;
   

Scala guidelines

1. In almost all cases, try to declare the data type of variables. E.g., prefer val x: Int = 5 over val x = 5. You can use some discretion here, particularly if the data type is very long and/or uninformative, which can happen when the type is coming from some library (like Slick). Another case where you could use discretion is if the type is pretty obvious, but it would make the code look much less readable or cause a line to go over the 120 character limit.
2. Use the Slick library for accessing the database instead of plain SQL whenever possible (because there is compiler type checking for it).
3. For comments/documentation, try to adhere to the Scaladoc style guide.

PostgreSQl guidelines