Been playing with these settings, pretty awesome so far. How do we feel about adding a check for spaces between concatenation/arithmetic: 'test'+b => 'test' + b?
On Fri, Aug 1, 2014 at 8:25 PM, Michal Mocny <[email protected]> wrote: > 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 >> > > > >> > > >> > >> > >
