Not having "reader mode" available for this webpage irritated me greatly because I hate serif'ed fonts and prefer how I have my reader mode configured.
My "rules" for readability. YMMV
Opening braces are syntactic sugar to allow for single line statements without braces. Using what the author calls ITBS and requiring braces avoids this.
Putting the "else if" and "else" on a separate line avoids the "} else if () {" structure and puts the "else" at the same syntactic level as the "if".
snake_case variables areMuchMoreReadable than camelCase.
Spaces (after_function_names) means that it is difficult to distinguish them from language keywords like while () and for () (in C/C++).
Excessive attempts at alignment on ":" or "=" boundaries or using a convenient arrangement for a particular group of declarations leads to inconsistencies that cannot be dealt with by an automatic formatter.
Function parameter declarations should be aligned one indent further than the name of the function with the brackets used in the same way as braces, so something like:
function my_function(
param_1,
param_2
) {
// body
}
My "rules" for readability. YMMV
Opening braces are syntactic sugar to allow for single line statements without braces. Using what the author calls ITBS and requiring braces avoids this.
Putting the "else if" and "else" on a separate line avoids the "} else if () {" structure and puts the "else" at the same syntactic level as the "if".
snake_case variables areMuchMoreReadable than camelCase.
Spaces (after_function_names) means that it is difficult to distinguish them from language keywords like while () and for () (in C/C++).
Excessive attempts at alignment on ":" or "=" boundaries or using a convenient arrangement for a particular group of declarations leads to inconsistencies that cannot be dealt with by an automatic formatter.
Function parameter declarations should be aligned one indent further than the name of the function with the brackets used in the same way as braces, so something like: