-
Notifications
You must be signed in to change notification settings - Fork 1
Style Guide
All new contributors should read the style guide. All pull requests will be reviewed (including those from the repo owner) and correct style will be required for a merge to master. We do not intend this to be used as a way to exclude users from contributing (we love contributors!), but to keep a clean and consistent code base.
Alright, so let's jump right in.
Unsure what style to use? Follow the style of similar code already in the code base.
Unsure what style to use and your style case seems to be some corner case not covered by previous code in the code base? It also isn't covered in this style guide? Use your best judgment. If your code style does not follow the guidelines, the person reviewing your pull request should point you in the right direction.
Comments should be followed by a space and begun with a capital letter.
// This is my comment
In general, comments should be used to explain why something is done, not how. Your code tells us how it is done. However, not all 'how' comments are bad. A short comment to briefly explain a code paragraph can go a long way in a new reader parsing a codebase, just don't overdo it.
We prefer multi-line comments to to be a succession of //s instead of using the /* and */ syntax.
// This is my multiline comment, I only used it because I ran out of space
// on one comment line
Constructors and instance methods should have full API documentation comments. See this UnisonOscillator constructor example:
// Constructor
// Creates unison oscillator object that's amplitude follows the envelope and is connected to the filter
// @param {string} wavetype - The waveform type for this unison oscillator
// @param {p5.Env} envelope - The envelope the oscillator's amplitude will be mapped to
// @param {p5.Filter} filter - The filter the source will go through
Variables should be camelCase except in the case of CONSTANTS_LIKE_THIS_ONE
Function names should be camelCase except in the case of ConstructorsLikeThisOne
If function foo is dependent on function bar, bar should be defined before foo (assuming they're in the same file).
Both variable and function names should be descriptive but succinct.
Open parenthesis should directly follow the function name.
thisIsMyFunction(thisIsMyArgument, thisIsAnotherArgument)
Private variable and function names should begin with an underscore, _
for, while, and if should all be followed by a space before the parenthesis.
for (var keysIndex in keyboardKeys)
if (i % 2 === 0)
Know that for...in is enumeration of properties in arbitrary order.
Since, in Javascript, the variable 'in' the iterable in a for...in is just an index, we prefer to name as such.
Open curly braces ({) start on the same line, preceded by a space.
function myFunction() {
Close curly braces (}) end on a new line.
Always use curly braces for loops and statements, regardless if they are a one-liner or not.
In JavaScript files, use single quotes ('). In HTML files, uses double quotes (").
In JavaScript, semicolons are optional. We choose to use them. End of a line should be indicated by a semicolon, ;
A single line should not exceed 85 characters in most cases. A single line should never exceed 100 characters.
The end of a file should be an empty newline after the final closed curly brace.