JavaScript

[jstayton]

Let's start collecting bits and pieces for our JavaScript conventions.

A few ideas to start:

1. Use JSHint. Add .jshintrc file that we can drop into our projects.
2. Find a baseline style guide that developers can read and learn. Perhaps Crockford?

[shanebonham]

Here's the .jshintrc I've been using: https://gist.github.com/aa5535307ece7e57ec2b

I believe it only differs from the one you supplied in the following ways (besides project specific globals):

"jquery": true, // defines globals exposed by jQuery
"devel": true, // globals that are usually used for debugging: console, alert, etc. It might make sense for us to *not* use this, depending on how we feel about shipping logging code.
"white": true // apparently checks against Crockford style, but the main reason I added it was to catch spacing around anonymous function calls

I like the Crockford style guide and I refer to it a lot, but it wouldn't surprise me if we find things about it we don't want to adhere to.

[jstayton]

@shanebonham I'm cool with white. jquery is a bit too project-specific. I don't think devel should be enabled because shipping code with logging is usually frowned upon. Otherwise, I think we're in agreement!

[jstayton]

I think we should include a section on jQuery. Some points:

1. Prefix jQuery element variables with $ (i.e., var $header = $('#header');).
2. If you Google "jquery best practices", you'll find a lot of the same rules. Maybe we should link to a few of them? Or just summarize them inline?

[jstayton]

A few more JavaScript ideas:

1. If loading a script from a third-party CDN, be sure to include a local fallback if it fails to load. Like for jQuery: <script>window.jQuery || document.write('<script src="/path/to/jquery.min.js"><\/script>');</script>
2. Use Bower for package management. The bower-rails gem is handy for Rails.
3. Don't pollute the global namespace. If possible, an app or library's code should all be contained within a single global variable/object. The module pattern and immediately-invoked function expressions are highly encouraged.
4. Good reference for JSHint errors: http://jslinterrors.com

[jstayton]

Airbnb JavaScript Style Guide: https://github.com/airbnb/javascript

[jstayton]

For the jQuery section: http://www.slideshare.net/AddyOsmani/jquery-proven-performance-tips-tricks/

[shanebonham]

I just realized we still don't have a .jshintrc file committed for mcms (which explains this ). I propose we use this config, or use that as a starting point since something is better than nothing.

(Side note related to this repo: it doesn't feel like we're doing ourselves any favors by putting all issues pertaining to a single subject in one GH issue. I propose we create issues as needed, and rather label them in a relevant way. I was also thinking again about @mcordell's suggesting of PRs against actual convention documentation, and I think that could be useful still.)

[jstayton]

I think that's a good idea. I was thinking these more general issues would be closed as each actual .md is created, then we'll be able to do PRs for more specific tweaks.

[shanebonham]

The white option was deprecated by JSHint, and they suggest jscs. Here's the (simple) config I use:

{
  "requireSpacesInAnonymousFunctionExpression": {
    "beforeOpeningRoundBrace": true,
    "beforeOpeningCurlyBrace": true
  },
  "validateIndentation": 2
}

[kennykaye]

I raised the topic of preprocessing assets in the HTML/CSS issue. This convention has ramifications on Javascript as well.

[rickyatmonk]

I've never been a fan of the single var requirement. I've just always found them unwieldy.

And, in fact the airbnb style guide does one var per line. https://github.com/airbnb/javascript#variables .

Since we're moving in the airbnb direction (and away from the single var practice), I thought you might appreciate this article that articulates why the single var practice can be troublesome: http://danhough.com/blog/single-var-pattern-rant/

[jstayton]

I'm in agreement, @rickyatmonk. After recently bringing Monk ID JS in line with the Airbnb style guide, I'm now a fan of multiple vars at the top. Thanks for sharing that article.

The other "personal" style I had to change is no longer putting a space in anonymous functions: function() {, not function () {. I'm good with that as well.

[shanebonham]

The var thing makes sense.

The function() { thing makes me gag. What's their rationale?

[jstayton]

They don't offer one, so I guess it's just their preference.

[kennykaye]

I'm strongly in favor of the Airbnb style guide. My personal preference for the anonymous functions is function () { but I would rather adhere to the guide as a whole as opposed to cherry-picking.