lgtm
On Fri, Aug 1, 2014 at 4:42 PM, Steven Gill <[email protected]> wrote: > All three parts look good to me! > > > On Fri, Aug 1, 2014 at 1:15 PM, Mark Koudritsky <[email protected]> wrote: > > > With and empty config file JSCS would emit no errors whatsoever. As more > > options are added, the more of a style JSCS enforces. Let's try it this > > way, I'll split the current config file into 3 sections and people > comment > > whether they think it should be enforced: > > > > ## Part 1, the whitespace basics I've rarely seen disagreement about > > Option names are self explanatory. > > > > "disallowMixedSpacesAndTabs": true, > > "disallowTrailingWhitespace": true, > > "validateLineBreaks": "LF", > > "validateIndentation": 4, > > "requireLineFeedAtFileEnd": true, > > > > ## Part 2, not universal but very common conventions. > > > > "disallowSpaceAfterPrefixUnaryOperators": true, > > "disallowSpaceBeforePostfixUnaryOperators": true, > > "requireSpaceAfterLineComment": true, > > "requireCapitalizedConstructors": true, > > cordova-lib code currently violates the last one with lower case > > constructors for hooker() (but that's being replaces in PR 55 > > <https://github.com/apache/cordova-lib/pull/55>) and platfroms[].parser. > > > > > > ## Part 3, somewhat arguable things but mostly adhered to by the existing > > cordova-lib code > > // function f(x) is ok but function f (x) is not: > > "disallowSpacesInNamedFunctionExpression": { > > "beforeOpeningRoundBrace": true > > }, > > // if (x>0) is ok but if(x>0) is not./ > > "requireSpaceAfterKeywords": [ > > "if", > > "else", > > "for", > > "while", > > "do" > > ] > > > > We could potentially add way way more options and create a fully fledged > > tight style, but that's definitely not my goal :) > > > > > > > > On Fri, Aug 1, 2014 at 2:56 PM, Steven Gill <[email protected]> > > wrote: > > > > > I personally am a little hesitant to have to follow a certain coding > > style > > > + am worried about outside contributors struggling with it. On the > other > > > hand, it would be nice for code readability to have uniform/consistent > > > style. > > > > > > As long as we discuss what styles we want to use beforehand, I am open > to > > > it. > > > > > > > > > On Thu, Jul 31, 2014 at 7:34 PM, Mark Koudritsky <[email protected]> > > > wrote: > > > > > > > Just opened a pull request with an experimental JSCS config. Would be > > > glad > > > > to get some feedback about this. My goal is to eventually run JSCS > > > together > > > > with JSHint as part of `npm test`. This is a relatively liberal > config > > > that > > > > doesn't generate too many warnings with the existing code. > > > > > > > > https://github.com/apache/cordova-lib/pull/69 > > > > > > > > > > > > ## Some background > > > > > > > > JSHint people want to focus on syntax linting and are dropping style > > > > oriented > > > > options. They recommend using JSCS (in addition to JSHint) for style: > > > > https://github.com/jshint/jshint/issues/1339 > > > > > > > > Options dropped from JSHint were added to JSCS some time ago: > > > > https://github.com/mdevils/node-jscs/issues/102 > > > > > > > > I'm using it with SublimeLinter-jscs > > > > https://sublime.wbond.net/packages/SublimeLinter-jscs > > > > > > > > > >
