Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of mmocny@google.com designates
 209.85.213.173 as permitted sender)
MIME-Version: 1.0
Sender: mmocny@google.com
In-Reply-To: 
 <CAEeF2Tfkj8ZsaJRooPiWRiqzAh4CHNas-Fh6x+5GPXG6ahR1cQ@mail.gmail.com>
References: 
 <CA+GVa3bx0Oawac3UuzuzqMfDB+srMkkhR11oAY8hJMKv9izicA@mail.gmail.com>
 <CAMSbhBjZSzPKyWhn0aJJr+Pv8PwodBfRKN1CJZCNtePSbKPhZQ@mail.gmail.com>
 <CA+GVa3Z1BjHR8O2Ve57PL_oFhMEaB8c=CAv7_qZ=BpDBgKhfaw@mail.gmail.com>
 <CAMSbhBja2M7ja0me0HP0jq_B=AZpavxMCAkL4qLrb76kwV30oQ@mail.gmail.com>
 <CAEeF2Tfkj8ZsaJRooPiWRiqzAh4CHNas-Fh6x+5GPXG6ahR1cQ@mail.gmail.com>
From: Michal Mocny <mmocny@chromium.org>
Date: Mon, 18 Aug 2014 10:59:32 -0400
Message-ID: 
 <CAEeF2TcJUaRuogfCJA4dG9C+6W9hH_6A1sqrU+d-q8rPX+HukA@mail.gmail.com>
Subject: Re: Experimenting with JSCS + JSHint in cordova-lib
To: Michal Mocny <mmocny@chromium.org>
Cc: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a11c1e8568af3ec0500e89fb9

--001a11c1e8568af3ec0500e89fb9
Content-Type: text/plain; charset=UTF-8

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 <mmocny@chromium.org> wrote:

> lgtm
>
>
> On Fri, Aug 1, 2014 at 4:42 PM, Steven Gill <stevengill97@gmail.com>
> wrote:
>
>> 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
>> > > >
>> > >
>> >
>>
>
>

--001a11c1e8568af3ec0500e89fb9--