You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Mark Koudritsky <ka...@google.com> on 2014/08/01 04:34:09 UTC
Experimenting with JSCS + JSHint in cordova-lib
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
Re: Experimenting with JSCS + JSHint in cordova-lib
Posted by "Terence M. Bandoian" <te...@tmbsw.com>.
Nicely done. Seems reasonable, well-organized and easy to understand.
-Terence Bandoian
On 8/1/2014 3:15 PM, Mark Koudritsky 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 <st...@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 <ka...@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
>>>
RE: Experimenting with JSCS + JSHint in cordova-lib
Posted by "Sergey Grebnov (Akvelon)" <v-...@microsoft.com>.
+1, thx you guys for driving this
-----Original Message-----
From: Shazron [mailto:shazron@gmail.com]
Sent: Tuesday, August 19, 2014 12:40 AM
To: dev@cordova.apache.org
Subject: Re: Experimenting with JSCS + JSHint in cordova-lib
I like it. +1
On Mon, Aug 18, 2014 at 7:59 AM, Michal Mocny <mm...@chromium.org> wrote:
> 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 <mm...@chromium.org> wrote:
>
>> lgtm
>>
>>
>> On Fri, Aug 1, 2014 at 4:42 PM, Steven Gill <st...@gmail.com>
>> wrote:
>>
>>> All three parts look good to me!
>>>
>>>
>>> On Fri, Aug 1, 2014 at 1:15 PM, Mark Koudritsky <ka...@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
>>> > <st...@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
>>> > > <ka...@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
>>> > > >
>>> > >
>>> >
>>>
>>
>>
Re: Experimenting with JSCS + JSHint in cordova-lib
Posted by Shazron <sh...@gmail.com>.
I like it. +1
On Mon, Aug 18, 2014 at 7:59 AM, Michal Mocny <mm...@chromium.org> wrote:
> 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 <mm...@chromium.org> wrote:
>
>> lgtm
>>
>>
>> On Fri, Aug 1, 2014 at 4:42 PM, Steven Gill <st...@gmail.com>
>> wrote:
>>
>>> All three parts look good to me!
>>>
>>>
>>> On Fri, Aug 1, 2014 at 1:15 PM, Mark Koudritsky <ka...@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 <st...@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 <ka...@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
>>> > > >
>>> > >
>>> >
>>>
>>
>>
Re: Experimenting with JSCS + JSHint in cordova-lib
Posted by Michal Mocny <mm...@chromium.org>.
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 <mm...@chromium.org> wrote:
> lgtm
>
>
> On Fri, Aug 1, 2014 at 4:42 PM, Steven Gill <st...@gmail.com>
> wrote:
>
>> All three parts look good to me!
>>
>>
>> On Fri, Aug 1, 2014 at 1:15 PM, Mark Koudritsky <ka...@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 <st...@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 <ka...@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
>> > > >
>> > >
>> >
>>
>
>
Re: Experimenting with JSCS + JSHint in cordova-lib
Posted by Michal Mocny <mm...@chromium.org>.
lgtm
On Fri, Aug 1, 2014 at 4:42 PM, Steven Gill <st...@gmail.com> wrote:
> All three parts look good to me!
>
>
> On Fri, Aug 1, 2014 at 1:15 PM, Mark Koudritsky <ka...@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 <st...@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 <ka...@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
> > > >
> > >
> >
>
Re: Experimenting with JSCS + JSHint in cordova-lib
Posted by Steven Gill <st...@gmail.com>.
All three parts look good to me!
On Fri, Aug 1, 2014 at 1:15 PM, Mark Koudritsky <ka...@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 <st...@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 <ka...@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
> > >
> >
>
Re: Experimenting with JSCS + JSHint in cordova-lib
Posted by Mark Koudritsky <ka...@google.com>.
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 <st...@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 <ka...@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
> >
>
Re: Experimenting with JSCS + JSHint in cordova-lib
Posted by Steven Gill <st...@gmail.com>.
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 <ka...@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
>