-
Notifications
You must be signed in to change notification settings - Fork 27
Style Guide
Mikey Saugstad edited this page Jul 2, 2020
·
13 revisions
- Keep lines <=120 characters long whenever it doesn't negatively impact readability.
- 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 - Use spaces instead of tabs.
- End all files with a newline character. You can tell if you did not by looking at your PR on Github.
- Spacing conventions:
- DO include a space:
- Before any open
{ - Between keywords such as
iforforand an open(
- Before any open
- DO NOT include a space:
- Between a function name and an open
( - Before and after operators like
+,&&, or==
- 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(); } }
- DO include a space:
- 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
- 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.
- 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.
- If you are declaring multiple variables, add a
varon each line:var do; var this;var not, this;
- Use the Slick library for accessing the database instead of plain SQL whenever possible (because there is compiler type checking for it).
- For comments/documentation, try to adhere to the Scaladoc style guide.