add editorconfig & jshint.

[stephenplusplus]

I know these crazy change sets aren't fun. Sorry :(

This PR introduces editorconfig and JSHint. The configuration files are at root level, then I went through and ran it against the code, which is how we got to the huge diff. There are some things I'm not crazy about; mainly the 80 character limit. There are a few cases in here where splitting into a new line just makes things ugly.

I hate to even say this, being that the diff is so huge, but this is still just an initial "sweep." There are other code-style things that I think can still be addressed.

Please take a look. You'll notice lots of new lines, semi-colons, variable renaming, variable declaring, use strict atop every file, and other small things. I'm happy to tighten or loosen any of these rules and go back over the code.

[rakyll]

This is great, much needed! I left some comments.

[stephenplusplus]

Combing over everything now 💇

[rakyll]

Ooops, can't merge automatically. Could you resolve the conflicts?

[stephenplusplus]

Just went through it and left in a second commit if you want to see that diff to make sure I'm following our new rules :).

[rakyll]

Too many vars :D Please let's do it for constants, enums only, please.

[stephenplusplus]

Too many vars :D Please let's do it for constants, enums only, please.

Haha. I think we have to stick to one style. We would run into the issue of having no sensible, detectable style guide. I think the problem we were solving for (this looking weird)...

var something = 'ok',
    somethingElse =
        'a really long string that goes on forever' +
        'and ever and ever',
    anotherThing = 3;

...so we instead isolated the long decl...

var anotherThing = 3;
var something = 'ok';

var somethingElse =
        'a really long string that goes on forever' +
        'and ever and ever';

...is something that will come up, const or not. Going through the code, I also came across another example of an exception to the rule:

// ...
var namespaceRegex = /^[A-Za-z]*$/;

/**
 * Conversion dict for query operation to operation proto value.
 * @type {Object}
 */
var opToOperatorDict = {
  '=':  'EQUAL',
  // ...

So our rule would be, use comma separation for var declarations, unless it's a constant, has a doc block, or is a really long string. I think we're opening the doors for headaches with that! Much more straightforward to use multiple var decls everywhere, imo.

[stephenplusplus]

And thank gosh, I finally fixed the merge conflicts! :)

[rakyll]

I think we're opening the doors for headaches with that! Much more straightforward to use multiple var decls everywhere, imo.

I think it'll be pretty straightforward to ask for such tweaks -- giving the fact that it's only a problem for long strings. Styling is about readability, we can't explain the verbosity of unnecessary vars either.

[rakyll]

OTOH, could you add yourself to CONTRIBUTORS file?

[stephenplusplus]

I think it'll be pretty straightforward to ask for such tweaks -- giving the fact that it's only a problem for long strings. Styling is about readability, we can't explain the verbosity of unnecessary vars either.

It's actually common to use multiple variable declarations. We aren't the exception to the standard here-- the truth is, either way is just as likely to be seen in a JS codebase. Multiple decls is often preferred for the reasons I mentioned earlier, which benefit the browser debugging process, but also for other reasons, such as being able to move a declaration up and down as necessary, without being concerned with leaving a missing comma or ending the decl block on a comma instead of a ;. This PR (JSHint) actually found an issue that would have been avoided by not relying on comma separation of declarations. If I remember right, something like:

var a = 'b'
    c = 'd';

I think there are lots of reasons to support using multiple var decls, but I'm not sure what's in the CONs column for multiple delcs (or the PROs column for comma-separated). You mentioned readability, but as a 90% js dev working in many codebases over the last few years with many different codestyles, multiple var decls doesn't make anything less readable to me, and I don't think others will be slowed down a bit. Again, they're equally common to see. Since we have doc blocks and a hard 80char limit, those are the two reasons I think multiple var decls makes sense for this codebase.

OTOH, could you add yourself to CONTRIBUTORS file?

Yes!

[rakyll]

Thanks much!

[stephenplusplus]

Yay!