Re: Experimenting with JSCS + JSHint in cordova-lib
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 mmo...@chromium.org wrote:
lgtm
On Fri, Aug 1, 2014 at 4:42 PM, Steven Gill stevengil...@gmail.com
wrote:
All three parts look good to me!
On Fri, Aug 1, 2014 at 1:15 PM, Mark Koudritsky kam...@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 (x0) is ok but if(x0) 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 stevengil...@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 kam...@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
I like it. +1
On Mon, Aug 18, 2014 at 7:59 AM, Michal Mocny mmo...@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 mmo...@chromium.org wrote:
lgtm
On Fri, Aug 1, 2014 at 4:42 PM, Steven Gill stevengil...@gmail.com
wrote:
All three parts look good to me!
On Fri, Aug 1, 2014 at 1:15 PM, Mark Koudritsky kam...@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 (x0) is ok but if(x0) 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 stevengil...@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 kam...@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
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 kam...@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
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 (x0) is ok but if(x0) 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 stevengil...@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 kam...@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
All three parts look good to me!
On Fri, Aug 1, 2014 at 1:15 PM, Mark Koudritsky kam...@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 (x0) is ok but if(x0) 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 stevengil...@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 kam...@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
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 (x0) is ok but if(x0) 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 stevengil...@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 kam...@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
lgtm
On Fri, Aug 1, 2014 at 4:42 PM, Steven Gill stevengil...@gmail.com wrote:
All three parts look good to me!
On Fri, Aug 1, 2014 at 1:15 PM, Mark Koudritsky kam...@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 (x0) is ok but if(x0) 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 stevengil...@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 kam...@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
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
