cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Gill <stevengil...@gmail.com>
Subject Re: Experimenting with JSCS + JSHint in cordova-lib
Date Fri, 01 Aug 2014 20:42:12 GMT
All three parts look good to me!


On Fri, Aug 1, 2014 at 1:15 PM, Mark Koudritsky <kamrik@google.com> 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 <stevengill97@gmail.com>
> 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 <kamrik@google.com>
> > 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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message