You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Martin Gonzalez Glez <ma...@gmail.com> on 2014/04/23 20:23:30 UTC
[Proposal] Cordova guidelines part of ContributorWorkflow
Hi guys,
As code contributor, I've been receiving feedback, comments, advice and
more from the commiters. Part of the received feedback is about the Cordova
code style, best practices, and
preferences about how to contribute code to the project, which existing
APIs to use, and more.
Because of that, I have added some advices about code style, practices and
preferences in the wiki page:
https://wiki.apache.org/cordova/StyleGuide
This kind of information it would be great for new Contributors involved in
code deliverance, to serve as initial guidance to follow.
That said, I have a *proposal *for all of you guys if are agree.
It's about adding this wiki page as part of the *ContributorWorkflow*; the
content attempts to explain basic styles, patterns, practices, and methods
used in the project. All new and existent code should conform to these
guidelines in order to maintain structural quality and code readability,
and to make software maintenance easier.
This could be a *win-win* for all of us, allowing contributors to provide
high quality code, and reducing the burden on committers to provide
individual feedback about the code style practices and standards that are
currently applied in the Cordova source code.
For contributors following these style guidelines, their code it will be
easier to review and merge into the project quickly.
Well, that's the proposal that I have, if you are agree with it, please
check the few lines that I've added to the Style guide page, and feel
yourself free to add more information, comments, practices,
recommendations, modify the current ones, whatever that you can provide it
would be great.
If you don't have permission to add information the Wiki page, you can ask
to a commiter for access to it. Or you can share a replay with the
information that you'd like to add, and I'll be happy to post it.
Thanks.
-Martin
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Martin Gonzalez Glez <ma...@gmail.com>.
Yes, agree. I can remove it.
2014-04-23 15:25 GMT-05:00 Mark Koudritsky <ka...@google.com>:
> The style guide contains the following two points that seem to partially
> contradict each other. Ok if we just delete the second one?
>
> 1. Remove unnecessary trailing whitespace in lines; this includes after
> operators, commas, semicolons or braces.
> 2. trailing spaces - you should turn off "remove trailing spaces" in
> your editor/IDE. That is, trailing spaces should be left in files. Not
> doing this yields extra diff junk, and sometime trailing spaces are
> significant.
>
>
>
> On Wed, Apr 23, 2014 at 2:41 PM, Shazron <sh...@gmail.com> wrote:
>
> > I'll add this to the wiki, but putting it out here as well for the other
> > platforms/plugins:
> >
> > cordova-ios uses uncrustify in a pre-commit hook:
> > https://github.com/apache/cordova-ios/tree/master/hooks that needs to be
> > added on a per clone basis. Saves me a lot of time when I do my own
> > commits. It can be configured for other languages. Could be a coho thing
> to
> > add these hooks when pulling down repos (gasp) ;)
> >
> > Also, regarding contributing, I added this issue for adding a
> > CONTRIBUTING.md to all our repos:
> > https://issues.apache.org/jira/browse/CB-6491
> >
> >
> >
> >
> >
> > On Wed, Apr 23, 2014 at 11:23 AM, Martin Gonzalez Glez <
> > martin.c.glez.glez@gmail.com> wrote:
> >
> > > Hi guys,
> > >
> > > As code contributor, I've been receiving feedback, comments, advice and
> > > more from the commiters. Part of the received feedback is about the
> > Cordova
> > > code style, best practices, and
> > > preferences about how to contribute code to the project, which existing
> > > APIs to use, and more.
> > >
> > > Because of that, I have added some advices about code style, practices
> > and
> > > preferences in the wiki page:
> > >
> > > https://wiki.apache.org/cordova/StyleGuide
> > >
> > > This kind of information it would be great for new Contributors
> involved
> > in
> > > code deliverance, to serve as initial guidance to follow.
> > >
> > > That said, I have a *proposal *for all of you guys if are agree.
> > > It's about adding this wiki page as part of the *ContributorWorkflow*;
> > the
> > > content attempts to explain basic styles, patterns, practices, and
> > methods
> > > used in the project. All new and existent code should conform to these
> > > guidelines in order to maintain structural quality and code
> readability,
> > > and to make software maintenance easier.
> > >
> > > This could be a *win-win* for all of us, allowing contributors to
> provide
> > > high quality code, and reducing the burden on committers to provide
> > > individual feedback about the code style practices and standards that
> are
> > > currently applied in the Cordova source code.
> > >
> > > For contributors following these style guidelines, their code it will
> be
> > > easier to review and merge into the project quickly.
> > >
> > > Well, that's the proposal that I have, if you are agree with it, please
> > > check the few lines that I've added to the Style guide page, and feel
> > > yourself free to add more information, comments, practices,
> > > recommendations, modify the current ones, whatever that you can provide
> > it
> > > would be great.
> > >
> > > If you don't have permission to add information the Wiki page, you can
> > ask
> > > to a commiter for access to it. Or you can share a replay with the
> > > information that you'd like to add, and I'll be happy to post it.
> > >
> > > Thanks.
> > > -Martin
> > >
> >
>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Marcel Kinard <cm...@gmail.com>.
I may be old school, but I like semicolons and agree.
On Jun 13, 2014, at 5:46 PM, Jesse <pu...@gmail.com> wrote:
> Rebooting this thread.
>
> I just noticed a ton of missing semicolons in the cordova-cli/src/cli.js,
> so I ran jshint and discovered that we explicitly set asi:true
>
> I don't think we agreed on semicolon use, I for one want to see semicolons
> because of the fact that they clearly demonstrate the intent of the
> developer.
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Jesse <pu...@gmail.com>.
Thanks Mark,
The styleguide was generally based on
http://javascript.crockford.com/code.html and crockford is pretty clear
that semicolons should be used.
Our text even says : '- brace on same line or crockford will kill you all
and semicolon insertion will expeditate the catacism.'
I think the disconnect is the addition of the 'comma-first' which is
somewhat conflicting as you point out. _brian!_
@purplecabbage
risingj.com
On Mon, Jun 16, 2014 at 1:23 PM, Martin Gonzalez <
martin.c.glez.glez@gmail.com> wrote:
> I'm agree with the use of semicolons. I think we should keep it consistent
> with the rest of the code, we should be on the same page about the code
> style.
>
> Regards.
>
>
> 2014-06-16 15:09 GMT-05:00 Mark Koudritsky <ka...@google.com>:
>
> > That was me who added "asi:true" and a bunch of code without semicolons
> in
> > cli.js. The short wiki doc we have for a style guide
> > <https://wiki.apache.org/cordova/StyleGuide#line-19> says that
> "semicolons
> > are unnecessary visual entropy ...". This is consistent with the
> > comma-first style it describes in general, as most comma-first style
> > evangelists also advocate for using no semicolons except where necessary.
> >
> > I somewhat took the comma-first style to its extreme in this refactoring
> of
> > cli.js. That's the benefit of having no real style guide - there is
> nothing
> > to violate - good for innovation in coding style :P
> > (big sarcasm sign here).
> >
> > Simple votes on separate style related questions can result in an overall
> > very strange style and are likely to leave many of us unhappy. Some other
> > mechanism is needed for coming up with a good coherent style guide. Last
> > time the issue of style guide was brought up on this list (iirc) people
> > were reluctant to continue in fear of holy wars and we stayed with the
> > current status-quo.
> >
> > Do we feel brave enough this time? Do we want to spend the time on this?
> > If yes, I'll be glad to start a separate thread with some rules to keep
> it
> > from deteriorating into a flame war.
> >
>
>
>
> --
> Regards,
> Martin Gonzalez
>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Brian LeRoux <b...@brian.io>.
we could do a batch reformat using:
https://github.com/rdio/jsfmt
On Tue, Jun 17, 2014 at 1:28 PM, Mark Koudritsky <ka...@google.com> wrote:
> JSHint is awesome and I'm slowly adding the JSHint config lines to almost
> every file I touch in cordova-lib.
> But as Shazron mentioned back in April in this thread, JSHint doesn't
> really focus on formatting. (he also suggested to look at jscs
> <https://github.com/mdevils/node-jscs> as additional tool).
>
>
> Anyway, lets start with using JSHint properly.
> Based on my experience so far, for the existing cordova-lib code I would
> recommend to start with this config:
>
> /* jshint node:true, bitwise:true, undef:true, trailing:true,
> quotmark:true,
> indent:4, unused:vars, latedef:nofunc
> */
>
> With the following optional tweaks for some files
> - laxcomma:true // If the file has comma-first formatted parts
> - sub:true // for files that parse XML and want to use node['prop'] where
> JSHint prefers node.prop.
> - expr:true // when you want to use variable && someFuncOn(variable);
> (which you shouldn't, but some of the existing code does).
>
> I've just pushed a change
> <
> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=8f880f5d3128e17c8a8f5a4c68798e11f9342172
> >
> with
> this config added to several files to try it out. Works great, I encourage
> people to try it out too.
> Once we get close to passing JSHint check for all the files, we should to
> add a JSHint stage to "npm test".
>
>
> As a reference - some stats from other projects:
> Below are the top 5 most popular .jshintrc files from 619 random* Node.js
> oriented projects on GitHub (lists of flags explicitly set to truthy values
> in .jshintrc).
>
> 1. bitwise, browser, camelcase, curly, eqeqeq, esnext, immed, indent,
> latedef, newcap, noarg, node, quotmark, regexp, smarttabs, strict,
> trailing, undef, unused
> 2. bitwise, browser, camelcase, curly, eqeqeq, es5, esnext, immed,
> indent, latedef, newcap, noarg, node, quotmark, regexp, smarttabs,
> strict,
> trailing, undef, unused
> 3. bitwise, browser, camelcase, curly, eqeqeq, esnext, immed, indent,
> jquery, latedef, newcap, noarg, node, quotmark, regexp, smarttabs,
> strict,
> trailing, undef, unused
> 4. bitwise, browser, camelcase, curly, eqeqeq, es5, esnext, globals,
> immed, indent, latedef, newcap, noarg, node, quotmark, regexp,
> smarttabs,
> strict, trailing, undef, unused
> 5. boss, curly, eqeqeq, eqnull, es5, immed, latedef, newcap, noarg,
> node, sub, undef
>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Mark Koudritsky <ka...@google.com>.
JSHint is awesome and I'm slowly adding the JSHint config lines to almost
every file I touch in cordova-lib.
But as Shazron mentioned back in April in this thread, JSHint doesn't
really focus on formatting. (he also suggested to look at jscs
<https://github.com/mdevils/node-jscs> as additional tool).
Anyway, lets start with using JSHint properly.
Based on my experience so far, for the existing cordova-lib code I would
recommend to start with this config:
/* jshint node:true, bitwise:true, undef:true, trailing:true, quotmark:true,
indent:4, unused:vars, latedef:nofunc
*/
With the following optional tweaks for some files
- laxcomma:true // If the file has comma-first formatted parts
- sub:true // for files that parse XML and want to use node['prop'] where
JSHint prefers node.prop.
- expr:true // when you want to use variable && someFuncOn(variable);
(which you shouldn't, but some of the existing code does).
I've just pushed a change
<https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=8f880f5d3128e17c8a8f5a4c68798e11f9342172>
with
this config added to several files to try it out. Works great, I encourage
people to try it out too.
Once we get close to passing JSHint check for all the files, we should to
add a JSHint stage to "npm test".
As a reference - some stats from other projects:
Below are the top 5 most popular .jshintrc files from 619 random* Node.js
oriented projects on GitHub (lists of flags explicitly set to truthy values
in .jshintrc).
1. bitwise, browser, camelcase, curly, eqeqeq, esnext, immed, indent,
latedef, newcap, noarg, node, quotmark, regexp, smarttabs, strict,
trailing, undef, unused
2. bitwise, browser, camelcase, curly, eqeqeq, es5, esnext, immed,
indent, latedef, newcap, noarg, node, quotmark, regexp, smarttabs, strict,
trailing, undef, unused
3. bitwise, browser, camelcase, curly, eqeqeq, esnext, immed, indent,
jquery, latedef, newcap, noarg, node, quotmark, regexp, smarttabs, strict,
trailing, undef, unused
4. bitwise, browser, camelcase, curly, eqeqeq, es5, esnext, globals,
immed, indent, latedef, newcap, noarg, node, quotmark, regexp, smarttabs,
strict, trailing, undef, unused
5. boss, curly, eqeqeq, eqnull, es5, immed, latedef, newcap, noarg,
node, sub, undef
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Brian LeRoux <b...@brian.io>.
No regrets. ;)
On Tue, Jun 17, 2014 at 10:49 AM, Michal Mocny <mm...@chromium.org> wrote:
> Don't tell me you would accept patches written using emacs?
>
>
> On Tue, Jun 17, 2014 at 12:45 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > +1
> >
> > For historical context, there was a time when finding/retaining
> committers
> > was more important than concern about the fickle style of JS that came
> into
> > fashion that week. We would even accept a pull request if it had tabs
> > instead of spaces!
> >
> > But ya lets go bananas on JSHint. Cleaning up those warnings would be a
> > good 'first bug' for new committers.
> >
> >
> >
> > On Mon, Jun 16, 2014 at 6:52 PM, Ian Clelland <ic...@chromium.org>
> > wrote:
> >
> > > /* jshint laxcomma: true */
> > >
> > > at the top of a JS file should do it.
> > >
> > > Ref: http://www.jshint.com/docs/options/#laxcomma
> > >
> > >
> > > On Mon, Jun 16, 2014 at 9:34 PM, Andrew Grieve <ag...@chromium.org>
> > > wrote:
> > >
> > > > I haven't seen our style guide followed, and generally don't think
> > style
> > > is
> > > > a thing that can really be enforced without tools or code review. How
> > > about
> > > > deleting the wiki page and doubling down on jshint? Can we tell
> jshint
> > to
> > > > force ;s while allowing comma-first?
> > > >
> > > >
> > > > On Mon, Jun 16, 2014 at 5:00 PM, Mark Koudritsky <ka...@google.com>
> > > > wrote:
> > > >
> > > > > To make it clear, I don't really care whether to use semicolons or
> > not,
> > > > but
> > > > > I do want cordova to have a style guide which I can follow without
> > > > > surprising people too much. Which is obviously not the case with
> our
> > > > > current style guide :)
> > > > >
> > > >
> > >
> >
>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Michal Mocny <mm...@chromium.org>.
Don't tell me you would accept patches written using emacs?
On Tue, Jun 17, 2014 at 12:45 PM, Brian LeRoux <b...@brian.io> wrote:
> +1
>
> For historical context, there was a time when finding/retaining committers
> was more important than concern about the fickle style of JS that came into
> fashion that week. We would even accept a pull request if it had tabs
> instead of spaces!
>
> But ya lets go bananas on JSHint. Cleaning up those warnings would be a
> good 'first bug' for new committers.
>
>
>
> On Mon, Jun 16, 2014 at 6:52 PM, Ian Clelland <ic...@chromium.org>
> wrote:
>
> > /* jshint laxcomma: true */
> >
> > at the top of a JS file should do it.
> >
> > Ref: http://www.jshint.com/docs/options/#laxcomma
> >
> >
> > On Mon, Jun 16, 2014 at 9:34 PM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> >
> > > I haven't seen our style guide followed, and generally don't think
> style
> > is
> > > a thing that can really be enforced without tools or code review. How
> > about
> > > deleting the wiki page and doubling down on jshint? Can we tell jshint
> to
> > > force ;s while allowing comma-first?
> > >
> > >
> > > On Mon, Jun 16, 2014 at 5:00 PM, Mark Koudritsky <ka...@google.com>
> > > wrote:
> > >
> > > > To make it clear, I don't really care whether to use semicolons or
> not,
> > > but
> > > > I do want cordova to have a style guide which I can follow without
> > > > surprising people too much. Which is obviously not the case with our
> > > > current style guide :)
> > > >
> > >
> >
>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Brian LeRoux <b...@brian.io>.
+1
For historical context, there was a time when finding/retaining committers
was more important than concern about the fickle style of JS that came into
fashion that week. We would even accept a pull request if it had tabs
instead of spaces!
But ya lets go bananas on JSHint. Cleaning up those warnings would be a
good 'first bug' for new committers.
On Mon, Jun 16, 2014 at 6:52 PM, Ian Clelland <ic...@chromium.org>
wrote:
> /* jshint laxcomma: true */
>
> at the top of a JS file should do it.
>
> Ref: http://www.jshint.com/docs/options/#laxcomma
>
>
> On Mon, Jun 16, 2014 at 9:34 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > I haven't seen our style guide followed, and generally don't think style
> is
> > a thing that can really be enforced without tools or code review. How
> about
> > deleting the wiki page and doubling down on jshint? Can we tell jshint to
> > force ;s while allowing comma-first?
> >
> >
> > On Mon, Jun 16, 2014 at 5:00 PM, Mark Koudritsky <ka...@google.com>
> > wrote:
> >
> > > To make it clear, I don't really care whether to use semicolons or not,
> > but
> > > I do want cordova to have a style guide which I can follow without
> > > surprising people too much. Which is obviously not the case with our
> > > current style guide :)
> > >
> >
>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Ian Clelland <ic...@chromium.org>.
/* jshint laxcomma: true */
at the top of a JS file should do it.
Ref: http://www.jshint.com/docs/options/#laxcomma
On Mon, Jun 16, 2014 at 9:34 PM, Andrew Grieve <ag...@chromium.org> wrote:
> I haven't seen our style guide followed, and generally don't think style is
> a thing that can really be enforced without tools or code review. How about
> deleting the wiki page and doubling down on jshint? Can we tell jshint to
> force ;s while allowing comma-first?
>
>
> On Mon, Jun 16, 2014 at 5:00 PM, Mark Koudritsky <ka...@google.com>
> wrote:
>
> > To make it clear, I don't really care whether to use semicolons or not,
> but
> > I do want cordova to have a style guide which I can follow without
> > surprising people too much. Which is obviously not the case with our
> > current style guide :)
> >
>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Andrew Grieve <ag...@chromium.org>.
I haven't seen our style guide followed, and generally don't think style is
a thing that can really be enforced without tools or code review. How about
deleting the wiki page and doubling down on jshint? Can we tell jshint to
force ;s while allowing comma-first?
On Mon, Jun 16, 2014 at 5:00 PM, Mark Koudritsky <ka...@google.com> wrote:
> To make it clear, I don't really care whether to use semicolons or not, but
> I do want cordova to have a style guide which I can follow without
> surprising people too much. Which is obviously not the case with our
> current style guide :)
>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Mark Koudritsky <ka...@google.com>.
To make it clear, I don't really care whether to use semicolons or not, but
I do want cordova to have a style guide which I can follow without
surprising people too much. Which is obviously not the case with our
current style guide :)
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Martin Gonzalez <ma...@gmail.com>.
I'm agree with the use of semicolons. I think we should keep it consistent
with the rest of the code, we should be on the same page about the code
style.
Regards.
2014-06-16 15:09 GMT-05:00 Mark Koudritsky <ka...@google.com>:
> That was me who added "asi:true" and a bunch of code without semicolons in
> cli.js. The short wiki doc we have for a style guide
> <https://wiki.apache.org/cordova/StyleGuide#line-19> says that "semicolons
> are unnecessary visual entropy ...". This is consistent with the
> comma-first style it describes in general, as most comma-first style
> evangelists also advocate for using no semicolons except where necessary.
>
> I somewhat took the comma-first style to its extreme in this refactoring of
> cli.js. That's the benefit of having no real style guide - there is nothing
> to violate - good for innovation in coding style :P
> (big sarcasm sign here).
>
> Simple votes on separate style related questions can result in an overall
> very strange style and are likely to leave many of us unhappy. Some other
> mechanism is needed for coming up with a good coherent style guide. Last
> time the issue of style guide was brought up on this list (iirc) people
> were reluctant to continue in fear of holy wars and we stayed with the
> current status-quo.
>
> Do we feel brave enough this time? Do we want to spend the time on this?
> If yes, I'll be glad to start a separate thread with some rules to keep it
> from deteriorating into a flame war.
>
--
Regards,
Martin Gonzalez
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Mark Koudritsky <ka...@google.com>.
That was me who added "asi:true" and a bunch of code without semicolons in
cli.js. The short wiki doc we have for a style guide
<https://wiki.apache.org/cordova/StyleGuide#line-19> says that "semicolons
are unnecessary visual entropy ...". This is consistent with the
comma-first style it describes in general, as most comma-first style
evangelists also advocate for using no semicolons except where necessary.
I somewhat took the comma-first style to its extreme in this refactoring of
cli.js. That's the benefit of having no real style guide - there is nothing
to violate - good for innovation in coding style :P
(big sarcasm sign here).
Simple votes on separate style related questions can result in an overall
very strange style and are likely to leave many of us unhappy. Some other
mechanism is needed for coming up with a good coherent style guide. Last
time the issue of style guide was brought up on this list (iirc) people
were reluctant to continue in fear of holy wars and we stayed with the
current status-quo.
Do we feel brave enough this time? Do we want to spend the time on this?
If yes, I'll be glad to start a separate thread with some rules to keep it
from deteriorating into a flame war.
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Michal Mocny <mm...@chromium.org>.
I don't think we need to vote for anything but releases. Unless we cannot
agree and decide a vote is all that can settle (unlikely).
FWIW, I also like semicolons, but I wasn't aware when/why this jshint
setting was made.
-Michal
On Fri, Jun 13, 2014 at 5:46 PM, Jesse <pu...@gmail.com> wrote:
> Rebooting this thread.
>
> I just noticed a ton of missing semicolons in the cordova-cli/src/cli.js,
> so I ran jshint and discovered that we explicitly set asi:true
>
> I don't think we agreed on semicolon use, I for one want to see semicolons
> because of the fact that they clearly demonstrate the intent of the
> developer.
>
> Let me know if we need a vote thread.
>
>
> @purplecabbage
> risingj.com
>
>
> On Fri, Apr 25, 2014 at 10:05 AM, Mark Koudritsky <ka...@google.com>
> wrote:
>
> > Jshint seems to have pretty good defaults, so a short config line like
> this
> > might be enough for most node js files we have.
> > /* jshint node:true, unused:true, indent:4 */
> > One very simple option it is to start adding this config line in every
> > file, and then just run jshint without any extra config.
> >
> > This also allows for slight variations between the files, e.g. sub:true
> is
> > useful for files that deal with XML parsing to prevent jshint from
> > complaining about doc['key'] where doc.key looks like better JS but is
> not
> > really appropriate because it's an XML doc.
> >
> > Jasmine files will need pretty long whitelist of globals since (afaik)
> > there is no Jasmine preset for jshint.
> > The other config method that allows for different configs for parts of
> the
> > project are several .jshintrc files, e.g. one in src/ and another one in
> > spec/.
> >
> >
> > On Thu, Apr 24, 2014 at 6:15 PM, Shazron <sh...@gmail.com> wrote:
> >
> > > jshint doesn't focus on formatting: jscs does, and is like uncrustify
> > that
> > > I mentioned.
> > >
> > > As for a jshint-like thing for non-JS platforms, for iOS - there is
> > OCLint
> > > http://oclint.org/
> > >
> > >
> > > On Thu, Apr 24, 2014 at 2:22 PM, Jesse <pu...@gmail.com>
> wrote:
> > >
> > > > I agree that jshint is awesome and powerful, I use it all the time,
> and
> > > so
> > > > should you.
> > > > That seems like a great end to this discussion ...
> > > > Otherwise, how do we address the 50% of our code that is not JS?
> > > >
> > > > @purplecabbage
> > > > risingj.com
> > > >
> > > >
> > > > On Thu, Apr 24, 2014 at 2:15 PM, Martin Gonzalez Glez <
> > > > martin.c.glez.glez@gmail.com> wrote:
> > > >
> > > > > jshint is really cool. Agree, +1 for jshint.
> > > > >
> > > > > A couple of questions about this, which are gonna be the validation
> > > > rules?
> > > > > I mean, we have to be in the same page about which are gonna be
> those
> > > > > rules.
> > > > > Besides, how the users are going to use it? First they need to have
> > the
> > > > > node module installed, and then, use a set of validation rules that
> > we
> > > > are
> > > > > going to provide?
> > > > >
> > > > > How it's gonna be? use a .jshintrc file with all the rules, general
> > > rules
> > > > > provided by the community, or each cordova component would contain
> a
> > > > > jshintConfig/package.json with specific validation rules.
> CLI+rules,
> > > > > platforms + rules, plugins + rules
> > > > > It's gonna be optional(recommended)or as requirement to deliver
> code,
> > > the
> > > > > usage of jshint before commit files? the contributors would need
> send
> > > any
> > > > > evidence, that proves that their code has passed the validation?
> > > > > Any thoughts?
> > > > >
> > > > > Jshint, it's awesome and a really good solution, I really like it.
> > > > >
> > > > > -Martin.
> > > > >
> > > > >
> > > > > 2014-04-24 10:55 GMT-05:00 Marcel Kinard <cm...@gmail.com>:
> > > > >
> > > > > > Big +1 for jshint.
> > > > > >
> > > > > > On Apr 23, 2014, at 5:53 PM, Brian LeRoux <b...@brian.io> wrote:
> > > > > >
> > > > > > > This may get rotten eggs thrown at me but I think it would be
> > good
> > > to
> > > > > add
> > > > > > > jshint to the project.
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Jesse <pu...@gmail.com>.
Rebooting this thread.
I just noticed a ton of missing semicolons in the cordova-cli/src/cli.js,
so I ran jshint and discovered that we explicitly set asi:true
I don't think we agreed on semicolon use, I for one want to see semicolons
because of the fact that they clearly demonstrate the intent of the
developer.
Let me know if we need a vote thread.
@purplecabbage
risingj.com
On Fri, Apr 25, 2014 at 10:05 AM, Mark Koudritsky <ka...@google.com> wrote:
> Jshint seems to have pretty good defaults, so a short config line like this
> might be enough for most node js files we have.
> /* jshint node:true, unused:true, indent:4 */
> One very simple option it is to start adding this config line in every
> file, and then just run jshint without any extra config.
>
> This also allows for slight variations between the files, e.g. sub:true is
> useful for files that deal with XML parsing to prevent jshint from
> complaining about doc['key'] where doc.key looks like better JS but is not
> really appropriate because it's an XML doc.
>
> Jasmine files will need pretty long whitelist of globals since (afaik)
> there is no Jasmine preset for jshint.
> The other config method that allows for different configs for parts of the
> project are several .jshintrc files, e.g. one in src/ and another one in
> spec/.
>
>
> On Thu, Apr 24, 2014 at 6:15 PM, Shazron <sh...@gmail.com> wrote:
>
> > jshint doesn't focus on formatting: jscs does, and is like uncrustify
> that
> > I mentioned.
> >
> > As for a jshint-like thing for non-JS platforms, for iOS - there is
> OCLint
> > http://oclint.org/
> >
> >
> > On Thu, Apr 24, 2014 at 2:22 PM, Jesse <pu...@gmail.com> wrote:
> >
> > > I agree that jshint is awesome and powerful, I use it all the time, and
> > so
> > > should you.
> > > That seems like a great end to this discussion ...
> > > Otherwise, how do we address the 50% of our code that is not JS?
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > >
> > > On Thu, Apr 24, 2014 at 2:15 PM, Martin Gonzalez Glez <
> > > martin.c.glez.glez@gmail.com> wrote:
> > >
> > > > jshint is really cool. Agree, +1 for jshint.
> > > >
> > > > A couple of questions about this, which are gonna be the validation
> > > rules?
> > > > I mean, we have to be in the same page about which are gonna be those
> > > > rules.
> > > > Besides, how the users are going to use it? First they need to have
> the
> > > > node module installed, and then, use a set of validation rules that
> we
> > > are
> > > > going to provide?
> > > >
> > > > How it's gonna be? use a .jshintrc file with all the rules, general
> > rules
> > > > provided by the community, or each cordova component would contain a
> > > > jshintConfig/package.json with specific validation rules. CLI+rules,
> > > > platforms + rules, plugins + rules
> > > > It's gonna be optional(recommended)or as requirement to deliver code,
> > the
> > > > usage of jshint before commit files? the contributors would need send
> > any
> > > > evidence, that proves that their code has passed the validation?
> > > > Any thoughts?
> > > >
> > > > Jshint, it's awesome and a really good solution, I really like it.
> > > >
> > > > -Martin.
> > > >
> > > >
> > > > 2014-04-24 10:55 GMT-05:00 Marcel Kinard <cm...@gmail.com>:
> > > >
> > > > > Big +1 for jshint.
> > > > >
> > > > > On Apr 23, 2014, at 5:53 PM, Brian LeRoux <b...@brian.io> wrote:
> > > > >
> > > > > > This may get rotten eggs thrown at me but I think it would be
> good
> > to
> > > > add
> > > > > > jshint to the project.
> > > > >
> > > >
> > >
> >
>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Mark Koudritsky <ka...@google.com>.
Jshint seems to have pretty good defaults, so a short config line like this
might be enough for most node js files we have.
/* jshint node:true, unused:true, indent:4 */
One very simple option it is to start adding this config line in every
file, and then just run jshint without any extra config.
This also allows for slight variations between the files, e.g. sub:true is
useful for files that deal with XML parsing to prevent jshint from
complaining about doc['key'] where doc.key looks like better JS but is not
really appropriate because it's an XML doc.
Jasmine files will need pretty long whitelist of globals since (afaik)
there is no Jasmine preset for jshint.
The other config method that allows for different configs for parts of the
project are several .jshintrc files, e.g. one in src/ and another one in
spec/.
On Thu, Apr 24, 2014 at 6:15 PM, Shazron <sh...@gmail.com> wrote:
> jshint doesn't focus on formatting: jscs does, and is like uncrustify that
> I mentioned.
>
> As for a jshint-like thing for non-JS platforms, for iOS - there is OCLint
> http://oclint.org/
>
>
> On Thu, Apr 24, 2014 at 2:22 PM, Jesse <pu...@gmail.com> wrote:
>
> > I agree that jshint is awesome and powerful, I use it all the time, and
> so
> > should you.
> > That seems like a great end to this discussion ...
> > Otherwise, how do we address the 50% of our code that is not JS?
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Thu, Apr 24, 2014 at 2:15 PM, Martin Gonzalez Glez <
> > martin.c.glez.glez@gmail.com> wrote:
> >
> > > jshint is really cool. Agree, +1 for jshint.
> > >
> > > A couple of questions about this, which are gonna be the validation
> > rules?
> > > I mean, we have to be in the same page about which are gonna be those
> > > rules.
> > > Besides, how the users are going to use it? First they need to have the
> > > node module installed, and then, use a set of validation rules that we
> > are
> > > going to provide?
> > >
> > > How it's gonna be? use a .jshintrc file with all the rules, general
> rules
> > > provided by the community, or each cordova component would contain a
> > > jshintConfig/package.json with specific validation rules. CLI+rules,
> > > platforms + rules, plugins + rules
> > > It's gonna be optional(recommended)or as requirement to deliver code,
> the
> > > usage of jshint before commit files? the contributors would need send
> any
> > > evidence, that proves that their code has passed the validation?
> > > Any thoughts?
> > >
> > > Jshint, it's awesome and a really good solution, I really like it.
> > >
> > > -Martin.
> > >
> > >
> > > 2014-04-24 10:55 GMT-05:00 Marcel Kinard <cm...@gmail.com>:
> > >
> > > > Big +1 for jshint.
> > > >
> > > > On Apr 23, 2014, at 5:53 PM, Brian LeRoux <b...@brian.io> wrote:
> > > >
> > > > > This may get rotten eggs thrown at me but I think it would be good
> to
> > > add
> > > > > jshint to the project.
> > > >
> > >
> >
>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Shazron <sh...@gmail.com>.
jshint doesn't focus on formatting: jscs does, and is like uncrustify that
I mentioned.
As for a jshint-like thing for non-JS platforms, for iOS - there is OCLint
http://oclint.org/
On Thu, Apr 24, 2014 at 2:22 PM, Jesse <pu...@gmail.com> wrote:
> I agree that jshint is awesome and powerful, I use it all the time, and so
> should you.
> That seems like a great end to this discussion ...
> Otherwise, how do we address the 50% of our code that is not JS?
>
> @purplecabbage
> risingj.com
>
>
> On Thu, Apr 24, 2014 at 2:15 PM, Martin Gonzalez Glez <
> martin.c.glez.glez@gmail.com> wrote:
>
> > jshint is really cool. Agree, +1 for jshint.
> >
> > A couple of questions about this, which are gonna be the validation
> rules?
> > I mean, we have to be in the same page about which are gonna be those
> > rules.
> > Besides, how the users are going to use it? First they need to have the
> > node module installed, and then, use a set of validation rules that we
> are
> > going to provide?
> >
> > How it's gonna be? use a .jshintrc file with all the rules, general rules
> > provided by the community, or each cordova component would contain a
> > jshintConfig/package.json with specific validation rules. CLI+rules,
> > platforms + rules, plugins + rules
> > It's gonna be optional(recommended)or as requirement to deliver code, the
> > usage of jshint before commit files? the contributors would need send any
> > evidence, that proves that their code has passed the validation?
> > Any thoughts?
> >
> > Jshint, it's awesome and a really good solution, I really like it.
> >
> > -Martin.
> >
> >
> > 2014-04-24 10:55 GMT-05:00 Marcel Kinard <cm...@gmail.com>:
> >
> > > Big +1 for jshint.
> > >
> > > On Apr 23, 2014, at 5:53 PM, Brian LeRoux <b...@brian.io> wrote:
> > >
> > > > This may get rotten eggs thrown at me but I think it would be good to
> > add
> > > > jshint to the project.
> > >
> >
>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Martin Gonzalez Glez <ma...@gmail.com>.
Yes, I'll start to use it no problem, but what about new contributors on
near future?. Like I said, which are gonna be the guidelines for them, or
the validation rules, this is resolved using just jshint to validate basic
criteria and that's it?
Good point, the code that's not JS. At the wiki page, it's just covered
guidelines for JS, not for any other languages.
2014-04-24 16:22 GMT-05:00 Jesse <pu...@gmail.com>:
> I agree that jshint is awesome and powerful, I use it all the time, and so
> should you.
> That seems like a great end to this discussion ...
> Otherwise, how do we address the 50% of our code that is not JS?
>
> @purplecabbage
> risingj.com
>
>
> On Thu, Apr 24, 2014 at 2:15 PM, Martin Gonzalez Glez <
> martin.c.glez.glez@gmail.com> wrote:
>
> > jshint is really cool. Agree, +1 for jshint.
> >
> > A couple of questions about this, which are gonna be the validation
> rules?
> > I mean, we have to be in the same page about which are gonna be those
> > rules.
> > Besides, how the users are going to use it? First they need to have the
> > node module installed, and then, use a set of validation rules that we
> are
> > going to provide?
> >
> > How it's gonna be? use a .jshintrc file with all the rules, general rules
> > provided by the community, or each cordova component would contain a
> > jshintConfig/package.json with specific validation rules. CLI+rules,
> > platforms + rules, plugins + rules
> > It's gonna be optional(recommended)or as requirement to deliver code, the
> > usage of jshint before commit files? the contributors would need send any
> > evidence, that proves that their code has passed the validation?
> > Any thoughts?
> >
> > Jshint, it's awesome and a really good solution, I really like it.
> >
> > -Martin.
> >
> >
> > 2014-04-24 10:55 GMT-05:00 Marcel Kinard <cm...@gmail.com>:
> >
> > > Big +1 for jshint.
> > >
> > > On Apr 23, 2014, at 5:53 PM, Brian LeRoux <b...@brian.io> wrote:
> > >
> > > > This may get rotten eggs thrown at me but I think it would be good to
> > add
> > > > jshint to the project.
> > >
> >
>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Jesse <pu...@gmail.com>.
I agree that jshint is awesome and powerful, I use it all the time, and so
should you.
That seems like a great end to this discussion ...
Otherwise, how do we address the 50% of our code that is not JS?
@purplecabbage
risingj.com
On Thu, Apr 24, 2014 at 2:15 PM, Martin Gonzalez Glez <
martin.c.glez.glez@gmail.com> wrote:
> jshint is really cool. Agree, +1 for jshint.
>
> A couple of questions about this, which are gonna be the validation rules?
> I mean, we have to be in the same page about which are gonna be those
> rules.
> Besides, how the users are going to use it? First they need to have the
> node module installed, and then, use a set of validation rules that we are
> going to provide?
>
> How it's gonna be? use a .jshintrc file with all the rules, general rules
> provided by the community, or each cordova component would contain a
> jshintConfig/package.json with specific validation rules. CLI+rules,
> platforms + rules, plugins + rules
> It's gonna be optional(recommended)or as requirement to deliver code, the
> usage of jshint before commit files? the contributors would need send any
> evidence, that proves that their code has passed the validation?
> Any thoughts?
>
> Jshint, it's awesome and a really good solution, I really like it.
>
> -Martin.
>
>
> 2014-04-24 10:55 GMT-05:00 Marcel Kinard <cm...@gmail.com>:
>
> > Big +1 for jshint.
> >
> > On Apr 23, 2014, at 5:53 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > This may get rotten eggs thrown at me but I think it would be good to
> add
> > > jshint to the project.
> >
>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Martin Gonzalez Glez <ma...@gmail.com>.
jshint is really cool. Agree, +1 for jshint.
A couple of questions about this, which are gonna be the validation rules?
I mean, we have to be in the same page about which are gonna be those rules.
Besides, how the users are going to use it? First they need to have the
node module installed, and then, use a set of validation rules that we are
going to provide?
How it's gonna be? use a .jshintrc file with all the rules, general rules
provided by the community, or each cordova component would contain a
jshintConfig/package.json with specific validation rules. CLI+rules,
platforms + rules, plugins + rules
It's gonna be optional(recommended)or as requirement to deliver code, the
usage of jshint before commit files? the contributors would need send any
evidence, that proves that their code has passed the validation?
Any thoughts?
Jshint, it's awesome and a really good solution, I really like it.
-Martin.
2014-04-24 10:55 GMT-05:00 Marcel Kinard <cm...@gmail.com>:
> Big +1 for jshint.
>
> On Apr 23, 2014, at 5:53 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > This may get rotten eggs thrown at me but I think it would be good to add
> > jshint to the project.
>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Marcel Kinard <cm...@gmail.com>.
Big +1 for jshint.
On Apr 23, 2014, at 5:53 PM, Brian LeRoux <b...@brian.io> wrote:
> This may get rotten eggs thrown at me but I think it would be good to add
> jshint to the project.
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Anis KADRI <an...@gmail.com>.
+1 for jshint.
On Wed, Apr 23, 2014 at 5:53 PM, Andrew Grieve <ag...@chromium.org> wrote:
> We already use jshint for cordova-js. Totally agree we should enabled
> it for plugman/cli & make it run as a part of "npm test".
>
> On Wed, Apr 23, 2014 at 6:13 PM, Mark Koudritsky <ka...@google.com>
> wrote:
> > +1 for jshint.
> >
> >
> > I've been using it for some time now and it helps me a lot. Especially
> for
> > catching the simple errors like typos bad indentation and forgotten
> "var".
> > Here is an example of jshint inline config in
> > plugman/src/util/config-changes.js<
> https://github.com/apache/cordova-plugman/blob/master/src/util/config-changes.js#L33
> >
> > .
> > /* jshint node:true, sub:true, unused:true, indent:4 */
> >
> > laxcomma:true - would be needed for comma first style.
> > asi:true - if we decide not to use semicolons (more
> > info<http://www.jshint.com/docs/options/#asi>)
> > which should probably go together with the comma first style.
> > sub:true - is specific to that file and shouldn't be used in others.
> >
> >
> >
> >
> > On Wed, Apr 23, 2014 at 5:53 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> >> This may get rotten eggs thrown at me but I think it would be good to
> add
> >> jshint to the project. The style guidelines are definitely not being
> >> followed in the wiki, and this is a good use for a tool. (Like
> uncrustify
> >> but moreso.) This way, whatever we decide is in fashion, can be
> consistent.
> >>
> >>
> >> And its totally cool if we change fashions over time. Having the
> entropy of
> >> changing styles isn't helpful.
> >>
> >>
> >> On Wed, Apr 23, 2014 at 2:29 PM, Martin Gonzalez Glez <
> >> martin.c.glez.glez@gmail.com> wrote:
> >>
> >> > Yes, we have to get to an agreement on that, and of course, we have to
> >> > follow the current style, I'm not proposing create a new style or
> follow
> >> > another style or pattern.
> >> > The whole listed items in Style Guide, are part of the feedback that
> so
> >> > far, I have received from commiters. What I was trying to point here,
> is
> >> > encourage the whole community to describe Cordova practices based on
> the
> >> > current code, on the current style, for those new contributors
> involved
> >> > with code deliverance.
> >> >
> >> > Of course Jesse, we should discuss this and get to an agreement, for
> all
> >> of
> >> > us follow those same guidelines.
> >> >
> >> > Thought: If Jesse reviews a contributor's PR, he surely will get some
> >> > feedback and guidance from Jesse, the contributor would think that
> based
> >> on
> >> > those practices that he learned from Jesse, it's the best way, the
> >> current
> >> > Code style. But maybe in another PR, Andrew reviews his code, he may
> >> point
> >> > to change some of the practices that he learn from Jesse. That may
> >> happen.
> >> > I'm not trying that everybody think in the same way, about how to
> create
> >> > logic. Just trying to set an starting point to explicitely describe,
> >> which
> >> > is the pattern of code style that we are using, in that way everyone
> is
> >> > going to be in the same page since the very beginning.
> >> >
> >> >
> >> >
> >> > 2014-04-23 15:35 GMT-05:00 Jesse <pu...@gmail.com>:
> >> >
> >> > > I agree with Andrew, there are several items in the style guide
> that I
> >> > > question.
> >> > > But mainly I question how a definitive guide can be defined without
> >> > > agreement ...
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > @purplecabbage
> >> > > risingj.com
> >> > >
> >> > >
> >> > > On Wed, Apr 23, 2014 at 1:30 PM, Andrew Grieve <
> agrieve@chromium.org>
> >> > > wrote:
> >> > >
> >> > > > In general, I think the only style guideline we need (at least
> for a
> >> > > > non-per-repo sense), is to follow whatever style currently exists.
> >> > > >
> >> > > > On Wed, Apr 23, 2014 at 4:25 PM, Mark Koudritsky <
> kamrik@google.com>
> >> > > > wrote:
> >> > > > > The style guide contains the following two points that seem to
> >> > > partially
> >> > > > > contradict each other. Ok if we just delete the second one?
> >> > > > >
> >> > > > > 1. Remove unnecessary trailing whitespace in lines; this
> >> includes
> >> > > > after
> >> > > > > operators, commas, semicolons or braces.
> >> > > > > 2. trailing spaces - you should turn off "remove trailing
> >> spaces"
> >> > in
> >> > > > > your editor/IDE. That is, trailing spaces should be left in
> >> files.
> >> > > Not
> >> > > > > doing this yields extra diff junk, and sometime trailing
> spaces
> >> > are
> >> > > > > significant.
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > On Wed, Apr 23, 2014 at 2:41 PM, Shazron <sh...@gmail.com>
> >> wrote:
> >> > > > >
> >> > > > >> I'll add this to the wiki, but putting it out here as well for
> the
> >> > > other
> >> > > > >> platforms/plugins:
> >> > > > >>
> >> > > > >> cordova-ios uses uncrustify in a pre-commit hook:
> >> > > > >> https://github.com/apache/cordova-ios/tree/master/hooks that
> >> needs
> >> > to
> >> > > > be
> >> > > > >> added on a per clone basis. Saves me a lot of time when I do my
> >> own
> >> > > > >> commits. It can be configured for other languages. Could be a
> coho
> >> > > > thing to
> >> > > > >> add these hooks when pulling down repos (gasp) ;)
> >> > > > >>
> >> > > > >> Also, regarding contributing, I added this issue for adding a
> >> > > > >> CONTRIBUTING.md to all our repos:
> >> > > > >> https://issues.apache.org/jira/browse/CB-6491
> >> > > > >>
> >> > > > >>
> >> > > > >>
> >> > > > >>
> >> > > > >>
> >> > > > >> On Wed, Apr 23, 2014 at 11:23 AM, Martin Gonzalez Glez <
> >> > > > >> martin.c.glez.glez@gmail.com> wrote:
> >> > > > >>
> >> > > > >> > Hi guys,
> >> > > > >> >
> >> > > > >> > As code contributor, I've been receiving feedback, comments,
> >> > advice
> >> > > > and
> >> > > > >> > more from the commiters. Part of the received feedback is
> about
> >> > the
> >> > > > >> Cordova
> >> > > > >> > code style, best practices, and
> >> > > > >> > preferences about how to contribute code to the project,
> which
> >> > > > existing
> >> > > > >> > APIs to use, and more.
> >> > > > >> >
> >> > > > >> > Because of that, I have added some advices about code style,
> >> > > practices
> >> > > > >> and
> >> > > > >> > preferences in the wiki page:
> >> > > > >> >
> >> > > > >> > https://wiki.apache.org/cordova/StyleGuide
> >> > > > >> >
> >> > > > >> > This kind of information it would be great for new
> Contributors
> >> > > > involved
> >> > > > >> in
> >> > > > >> > code deliverance, to serve as initial guidance to follow.
> >> > > > >> >
> >> > > > >> > That said, I have a *proposal *for all of you guys if are
> agree.
> >> > > > >> > It's about adding this wiki page as part of the
> >> > > *ContributorWorkflow*;
> >> > > > >> the
> >> > > > >> > content attempts to explain basic styles, patterns,
> practices,
> >> and
> >> > > > >> methods
> >> > > > >> > used in the project. All new and existent code should
> conform to
> >> > > these
> >> > > > >> > guidelines in order to maintain structural quality and code
> >> > > > readability,
> >> > > > >> > and to make software maintenance easier.
> >> > > > >> >
> >> > > > >> > This could be a *win-win* for all of us, allowing
> contributors
> >> to
> >> > > > provide
> >> > > > >> > high quality code, and reducing the burden on committers to
> >> > provide
> >> > > > >> > individual feedback about the code style practices and
> standards
> >> > > that
> >> > > > are
> >> > > > >> > currently applied in the Cordova source code.
> >> > > > >> >
> >> > > > >> > For contributors following these style guidelines, their
> code it
> >> > > will
> >> > > > be
> >> > > > >> > easier to review and merge into the project quickly.
> >> > > > >> >
> >> > > > >> > Well, that's the proposal that I have, if you are agree with
> it,
> >> > > > please
> >> > > > >> > check the few lines that I've added to the Style guide page,
> and
> >> > > feel
> >> > > > >> > yourself free to add more information, comments, practices,
> >> > > > >> > recommendations, modify the current ones, whatever that you
> can
> >> > > > provide
> >> > > > >> it
> >> > > > >> > would be great.
> >> > > > >> >
> >> > > > >> > If you don't have permission to add information the Wiki
> page,
> >> you
> >> > > can
> >> > > > >> ask
> >> > > > >> > to a commiter for access to it. Or you can share a replay
> with
> >> the
> >> > > > >> > information that you'd like to add, and I'll be happy to post
> >> it.
> >> > > > >> >
> >> > > > >> > Thanks.
> >> > > > >> > -Martin
> >> > > > >> >
> >> > > > >>
> >> > > >
> >> > >
> >> >
> >>
>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Andrew Grieve <ag...@chromium.org>.
We already use jshint for cordova-js. Totally agree we should enabled
it for plugman/cli & make it run as a part of "npm test".
On Wed, Apr 23, 2014 at 6:13 PM, Mark Koudritsky <ka...@google.com> wrote:
> +1 for jshint.
>
>
> I've been using it for some time now and it helps me a lot. Especially for
> catching the simple errors like typos bad indentation and forgotten "var".
> Here is an example of jshint inline config in
> plugman/src/util/config-changes.js<https://github.com/apache/cordova-plugman/blob/master/src/util/config-changes.js#L33>
> .
> /* jshint node:true, sub:true, unused:true, indent:4 */
>
> laxcomma:true - would be needed for comma first style.
> asi:true - if we decide not to use semicolons (more
> info<http://www.jshint.com/docs/options/#asi>)
> which should probably go together with the comma first style.
> sub:true - is specific to that file and shouldn't be used in others.
>
>
>
>
> On Wed, Apr 23, 2014 at 5:53 PM, Brian LeRoux <b...@brian.io> wrote:
>
>> This may get rotten eggs thrown at me but I think it would be good to add
>> jshint to the project. The style guidelines are definitely not being
>> followed in the wiki, and this is a good use for a tool. (Like uncrustify
>> but moreso.) This way, whatever we decide is in fashion, can be consistent.
>>
>>
>> And its totally cool if we change fashions over time. Having the entropy of
>> changing styles isn't helpful.
>>
>>
>> On Wed, Apr 23, 2014 at 2:29 PM, Martin Gonzalez Glez <
>> martin.c.glez.glez@gmail.com> wrote:
>>
>> > Yes, we have to get to an agreement on that, and of course, we have to
>> > follow the current style, I'm not proposing create a new style or follow
>> > another style or pattern.
>> > The whole listed items in Style Guide, are part of the feedback that so
>> > far, I have received from commiters. What I was trying to point here, is
>> > encourage the whole community to describe Cordova practices based on the
>> > current code, on the current style, for those new contributors involved
>> > with code deliverance.
>> >
>> > Of course Jesse, we should discuss this and get to an agreement, for all
>> of
>> > us follow those same guidelines.
>> >
>> > Thought: If Jesse reviews a contributor's PR, he surely will get some
>> > feedback and guidance from Jesse, the contributor would think that based
>> on
>> > those practices that he learned from Jesse, it's the best way, the
>> current
>> > Code style. But maybe in another PR, Andrew reviews his code, he may
>> point
>> > to change some of the practices that he learn from Jesse. That may
>> happen.
>> > I'm not trying that everybody think in the same way, about how to create
>> > logic. Just trying to set an starting point to explicitely describe,
>> which
>> > is the pattern of code style that we are using, in that way everyone is
>> > going to be in the same page since the very beginning.
>> >
>> >
>> >
>> > 2014-04-23 15:35 GMT-05:00 Jesse <pu...@gmail.com>:
>> >
>> > > I agree with Andrew, there are several items in the style guide that I
>> > > question.
>> > > But mainly I question how a definitive guide can be defined without
>> > > agreement ...
>> > >
>> > >
>> > >
>> > >
>> > > @purplecabbage
>> > > risingj.com
>> > >
>> > >
>> > > On Wed, Apr 23, 2014 at 1:30 PM, Andrew Grieve <ag...@chromium.org>
>> > > wrote:
>> > >
>> > > > In general, I think the only style guideline we need (at least for a
>> > > > non-per-repo sense), is to follow whatever style currently exists.
>> > > >
>> > > > On Wed, Apr 23, 2014 at 4:25 PM, Mark Koudritsky <ka...@google.com>
>> > > > wrote:
>> > > > > The style guide contains the following two points that seem to
>> > > partially
>> > > > > contradict each other. Ok if we just delete the second one?
>> > > > >
>> > > > > 1. Remove unnecessary trailing whitespace in lines; this
>> includes
>> > > > after
>> > > > > operators, commas, semicolons or braces.
>> > > > > 2. trailing spaces - you should turn off "remove trailing
>> spaces"
>> > in
>> > > > > your editor/IDE. That is, trailing spaces should be left in
>> files.
>> > > Not
>> > > > > doing this yields extra diff junk, and sometime trailing spaces
>> > are
>> > > > > significant.
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Wed, Apr 23, 2014 at 2:41 PM, Shazron <sh...@gmail.com>
>> wrote:
>> > > > >
>> > > > >> I'll add this to the wiki, but putting it out here as well for the
>> > > other
>> > > > >> platforms/plugins:
>> > > > >>
>> > > > >> cordova-ios uses uncrustify in a pre-commit hook:
>> > > > >> https://github.com/apache/cordova-ios/tree/master/hooks that
>> needs
>> > to
>> > > > be
>> > > > >> added on a per clone basis. Saves me a lot of time when I do my
>> own
>> > > > >> commits. It can be configured for other languages. Could be a coho
>> > > > thing to
>> > > > >> add these hooks when pulling down repos (gasp) ;)
>> > > > >>
>> > > > >> Also, regarding contributing, I added this issue for adding a
>> > > > >> CONTRIBUTING.md to all our repos:
>> > > > >> https://issues.apache.org/jira/browse/CB-6491
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> On Wed, Apr 23, 2014 at 11:23 AM, Martin Gonzalez Glez <
>> > > > >> martin.c.glez.glez@gmail.com> wrote:
>> > > > >>
>> > > > >> > Hi guys,
>> > > > >> >
>> > > > >> > As code contributor, I've been receiving feedback, comments,
>> > advice
>> > > > and
>> > > > >> > more from the commiters. Part of the received feedback is about
>> > the
>> > > > >> Cordova
>> > > > >> > code style, best practices, and
>> > > > >> > preferences about how to contribute code to the project, which
>> > > > existing
>> > > > >> > APIs to use, and more.
>> > > > >> >
>> > > > >> > Because of that, I have added some advices about code style,
>> > > practices
>> > > > >> and
>> > > > >> > preferences in the wiki page:
>> > > > >> >
>> > > > >> > https://wiki.apache.org/cordova/StyleGuide
>> > > > >> >
>> > > > >> > This kind of information it would be great for new Contributors
>> > > > involved
>> > > > >> in
>> > > > >> > code deliverance, to serve as initial guidance to follow.
>> > > > >> >
>> > > > >> > That said, I have a *proposal *for all of you guys if are agree.
>> > > > >> > It's about adding this wiki page as part of the
>> > > *ContributorWorkflow*;
>> > > > >> the
>> > > > >> > content attempts to explain basic styles, patterns, practices,
>> and
>> > > > >> methods
>> > > > >> > used in the project. All new and existent code should conform to
>> > > these
>> > > > >> > guidelines in order to maintain structural quality and code
>> > > > readability,
>> > > > >> > and to make software maintenance easier.
>> > > > >> >
>> > > > >> > This could be a *win-win* for all of us, allowing contributors
>> to
>> > > > provide
>> > > > >> > high quality code, and reducing the burden on committers to
>> > provide
>> > > > >> > individual feedback about the code style practices and standards
>> > > that
>> > > > are
>> > > > >> > currently applied in the Cordova source code.
>> > > > >> >
>> > > > >> > For contributors following these style guidelines, their code it
>> > > will
>> > > > be
>> > > > >> > easier to review and merge into the project quickly.
>> > > > >> >
>> > > > >> > Well, that's the proposal that I have, if you are agree with it,
>> > > > please
>> > > > >> > check the few lines that I've added to the Style guide page, and
>> > > feel
>> > > > >> > yourself free to add more information, comments, practices,
>> > > > >> > recommendations, modify the current ones, whatever that you can
>> > > > provide
>> > > > >> it
>> > > > >> > would be great.
>> > > > >> >
>> > > > >> > If you don't have permission to add information the Wiki page,
>> you
>> > > can
>> > > > >> ask
>> > > > >> > to a commiter for access to it. Or you can share a replay with
>> the
>> > > > >> > information that you'd like to add, and I'll be happy to post
>> it.
>> > > > >> >
>> > > > >> > Thanks.
>> > > > >> > -Martin
>> > > > >> >
>> > > > >>
>> > > >
>> > >
>> >
>>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Mark Koudritsky <ka...@google.com>.
+1 for jshint.
I've been using it for some time now and it helps me a lot. Especially for
catching the simple errors like typos bad indentation and forgotten "var".
Here is an example of jshint inline config in
plugman/src/util/config-changes.js<https://github.com/apache/cordova-plugman/blob/master/src/util/config-changes.js#L33>
.
/* jshint node:true, sub:true, unused:true, indent:4 */
laxcomma:true - would be needed for comma first style.
asi:true - if we decide not to use semicolons (more
info<http://www.jshint.com/docs/options/#asi>)
which should probably go together with the comma first style.
sub:true - is specific to that file and shouldn't be used in others.
On Wed, Apr 23, 2014 at 5:53 PM, Brian LeRoux <b...@brian.io> wrote:
> This may get rotten eggs thrown at me but I think it would be good to add
> jshint to the project. The style guidelines are definitely not being
> followed in the wiki, and this is a good use for a tool. (Like uncrustify
> but moreso.) This way, whatever we decide is in fashion, can be consistent.
>
>
> And its totally cool if we change fashions over time. Having the entropy of
> changing styles isn't helpful.
>
>
> On Wed, Apr 23, 2014 at 2:29 PM, Martin Gonzalez Glez <
> martin.c.glez.glez@gmail.com> wrote:
>
> > Yes, we have to get to an agreement on that, and of course, we have to
> > follow the current style, I'm not proposing create a new style or follow
> > another style or pattern.
> > The whole listed items in Style Guide, are part of the feedback that so
> > far, I have received from commiters. What I was trying to point here, is
> > encourage the whole community to describe Cordova practices based on the
> > current code, on the current style, for those new contributors involved
> > with code deliverance.
> >
> > Of course Jesse, we should discuss this and get to an agreement, for all
> of
> > us follow those same guidelines.
> >
> > Thought: If Jesse reviews a contributor's PR, he surely will get some
> > feedback and guidance from Jesse, the contributor would think that based
> on
> > those practices that he learned from Jesse, it's the best way, the
> current
> > Code style. But maybe in another PR, Andrew reviews his code, he may
> point
> > to change some of the practices that he learn from Jesse. That may
> happen.
> > I'm not trying that everybody think in the same way, about how to create
> > logic. Just trying to set an starting point to explicitely describe,
> which
> > is the pattern of code style that we are using, in that way everyone is
> > going to be in the same page since the very beginning.
> >
> >
> >
> > 2014-04-23 15:35 GMT-05:00 Jesse <pu...@gmail.com>:
> >
> > > I agree with Andrew, there are several items in the style guide that I
> > > question.
> > > But mainly I question how a definitive guide can be defined without
> > > agreement ...
> > >
> > >
> > >
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > >
> > > On Wed, Apr 23, 2014 at 1:30 PM, Andrew Grieve <ag...@chromium.org>
> > > wrote:
> > >
> > > > In general, I think the only style guideline we need (at least for a
> > > > non-per-repo sense), is to follow whatever style currently exists.
> > > >
> > > > On Wed, Apr 23, 2014 at 4:25 PM, Mark Koudritsky <ka...@google.com>
> > > > wrote:
> > > > > The style guide contains the following two points that seem to
> > > partially
> > > > > contradict each other. Ok if we just delete the second one?
> > > > >
> > > > > 1. Remove unnecessary trailing whitespace in lines; this
> includes
> > > > after
> > > > > operators, commas, semicolons or braces.
> > > > > 2. trailing spaces - you should turn off "remove trailing
> spaces"
> > in
> > > > > your editor/IDE. That is, trailing spaces should be left in
> files.
> > > Not
> > > > > doing this yields extra diff junk, and sometime trailing spaces
> > are
> > > > > significant.
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Apr 23, 2014 at 2:41 PM, Shazron <sh...@gmail.com>
> wrote:
> > > > >
> > > > >> I'll add this to the wiki, but putting it out here as well for the
> > > other
> > > > >> platforms/plugins:
> > > > >>
> > > > >> cordova-ios uses uncrustify in a pre-commit hook:
> > > > >> https://github.com/apache/cordova-ios/tree/master/hooks that
> needs
> > to
> > > > be
> > > > >> added on a per clone basis. Saves me a lot of time when I do my
> own
> > > > >> commits. It can be configured for other languages. Could be a coho
> > > > thing to
> > > > >> add these hooks when pulling down repos (gasp) ;)
> > > > >>
> > > > >> Also, regarding contributing, I added this issue for adding a
> > > > >> CONTRIBUTING.md to all our repos:
> > > > >> https://issues.apache.org/jira/browse/CB-6491
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Wed, Apr 23, 2014 at 11:23 AM, Martin Gonzalez Glez <
> > > > >> martin.c.glez.glez@gmail.com> wrote:
> > > > >>
> > > > >> > Hi guys,
> > > > >> >
> > > > >> > As code contributor, I've been receiving feedback, comments,
> > advice
> > > > and
> > > > >> > more from the commiters. Part of the received feedback is about
> > the
> > > > >> Cordova
> > > > >> > code style, best practices, and
> > > > >> > preferences about how to contribute code to the project, which
> > > > existing
> > > > >> > APIs to use, and more.
> > > > >> >
> > > > >> > Because of that, I have added some advices about code style,
> > > practices
> > > > >> and
> > > > >> > preferences in the wiki page:
> > > > >> >
> > > > >> > https://wiki.apache.org/cordova/StyleGuide
> > > > >> >
> > > > >> > This kind of information it would be great for new Contributors
> > > > involved
> > > > >> in
> > > > >> > code deliverance, to serve as initial guidance to follow.
> > > > >> >
> > > > >> > That said, I have a *proposal *for all of you guys if are agree.
> > > > >> > It's about adding this wiki page as part of the
> > > *ContributorWorkflow*;
> > > > >> the
> > > > >> > content attempts to explain basic styles, patterns, practices,
> and
> > > > >> methods
> > > > >> > used in the project. All new and existent code should conform to
> > > these
> > > > >> > guidelines in order to maintain structural quality and code
> > > > readability,
> > > > >> > and to make software maintenance easier.
> > > > >> >
> > > > >> > This could be a *win-win* for all of us, allowing contributors
> to
> > > > provide
> > > > >> > high quality code, and reducing the burden on committers to
> > provide
> > > > >> > individual feedback about the code style practices and standards
> > > that
> > > > are
> > > > >> > currently applied in the Cordova source code.
> > > > >> >
> > > > >> > For contributors following these style guidelines, their code it
> > > will
> > > > be
> > > > >> > easier to review and merge into the project quickly.
> > > > >> >
> > > > >> > Well, that's the proposal that I have, if you are agree with it,
> > > > please
> > > > >> > check the few lines that I've added to the Style guide page, and
> > > feel
> > > > >> > yourself free to add more information, comments, practices,
> > > > >> > recommendations, modify the current ones, whatever that you can
> > > > provide
> > > > >> it
> > > > >> > would be great.
> > > > >> >
> > > > >> > If you don't have permission to add information the Wiki page,
> you
> > > can
> > > > >> ask
> > > > >> > to a commiter for access to it. Or you can share a replay with
> the
> > > > >> > information that you'd like to add, and I'll be happy to post
> it.
> > > > >> >
> > > > >> > Thanks.
> > > > >> > -Martin
> > > > >> >
> > > > >>
> > > >
> > >
> >
>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Brian LeRoux <b...@brian.io>.
This may get rotten eggs thrown at me but I think it would be good to add
jshint to the project. The style guidelines are definitely not being
followed in the wiki, and this is a good use for a tool. (Like uncrustify
but moreso.) This way, whatever we decide is in fashion, can be consistent.
And its totally cool if we change fashions over time. Having the entropy of
changing styles isn't helpful.
On Wed, Apr 23, 2014 at 2:29 PM, Martin Gonzalez Glez <
martin.c.glez.glez@gmail.com> wrote:
> Yes, we have to get to an agreement on that, and of course, we have to
> follow the current style, I'm not proposing create a new style or follow
> another style or pattern.
> The whole listed items in Style Guide, are part of the feedback that so
> far, I have received from commiters. What I was trying to point here, is
> encourage the whole community to describe Cordova practices based on the
> current code, on the current style, for those new contributors involved
> with code deliverance.
>
> Of course Jesse, we should discuss this and get to an agreement, for all of
> us follow those same guidelines.
>
> Thought: If Jesse reviews a contributor's PR, he surely will get some
> feedback and guidance from Jesse, the contributor would think that based on
> those practices that he learned from Jesse, it's the best way, the current
> Code style. But maybe in another PR, Andrew reviews his code, he may point
> to change some of the practices that he learn from Jesse. That may happen.
> I'm not trying that everybody think in the same way, about how to create
> logic. Just trying to set an starting point to explicitely describe, which
> is the pattern of code style that we are using, in that way everyone is
> going to be in the same page since the very beginning.
>
>
>
> 2014-04-23 15:35 GMT-05:00 Jesse <pu...@gmail.com>:
>
> > I agree with Andrew, there are several items in the style guide that I
> > question.
> > But mainly I question how a definitive guide can be defined without
> > agreement ...
> >
> >
> >
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Wed, Apr 23, 2014 at 1:30 PM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> >
> > > In general, I think the only style guideline we need (at least for a
> > > non-per-repo sense), is to follow whatever style currently exists.
> > >
> > > On Wed, Apr 23, 2014 at 4:25 PM, Mark Koudritsky <ka...@google.com>
> > > wrote:
> > > > The style guide contains the following two points that seem to
> > partially
> > > > contradict each other. Ok if we just delete the second one?
> > > >
> > > > 1. Remove unnecessary trailing whitespace in lines; this includes
> > > after
> > > > operators, commas, semicolons or braces.
> > > > 2. trailing spaces - you should turn off "remove trailing spaces"
> in
> > > > your editor/IDE. That is, trailing spaces should be left in files.
> > Not
> > > > doing this yields extra diff junk, and sometime trailing spaces
> are
> > > > significant.
> > > >
> > > >
> > > >
> > > > On Wed, Apr 23, 2014 at 2:41 PM, Shazron <sh...@gmail.com> wrote:
> > > >
> > > >> I'll add this to the wiki, but putting it out here as well for the
> > other
> > > >> platforms/plugins:
> > > >>
> > > >> cordova-ios uses uncrustify in a pre-commit hook:
> > > >> https://github.com/apache/cordova-ios/tree/master/hooks that needs
> to
> > > be
> > > >> added on a per clone basis. Saves me a lot of time when I do my own
> > > >> commits. It can be configured for other languages. Could be a coho
> > > thing to
> > > >> add these hooks when pulling down repos (gasp) ;)
> > > >>
> > > >> Also, regarding contributing, I added this issue for adding a
> > > >> CONTRIBUTING.md to all our repos:
> > > >> https://issues.apache.org/jira/browse/CB-6491
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On Wed, Apr 23, 2014 at 11:23 AM, Martin Gonzalez Glez <
> > > >> martin.c.glez.glez@gmail.com> wrote:
> > > >>
> > > >> > Hi guys,
> > > >> >
> > > >> > As code contributor, I've been receiving feedback, comments,
> advice
> > > and
> > > >> > more from the commiters. Part of the received feedback is about
> the
> > > >> Cordova
> > > >> > code style, best practices, and
> > > >> > preferences about how to contribute code to the project, which
> > > existing
> > > >> > APIs to use, and more.
> > > >> >
> > > >> > Because of that, I have added some advices about code style,
> > practices
> > > >> and
> > > >> > preferences in the wiki page:
> > > >> >
> > > >> > https://wiki.apache.org/cordova/StyleGuide
> > > >> >
> > > >> > This kind of information it would be great for new Contributors
> > > involved
> > > >> in
> > > >> > code deliverance, to serve as initial guidance to follow.
> > > >> >
> > > >> > That said, I have a *proposal *for all of you guys if are agree.
> > > >> > It's about adding this wiki page as part of the
> > *ContributorWorkflow*;
> > > >> the
> > > >> > content attempts to explain basic styles, patterns, practices, and
> > > >> methods
> > > >> > used in the project. All new and existent code should conform to
> > these
> > > >> > guidelines in order to maintain structural quality and code
> > > readability,
> > > >> > and to make software maintenance easier.
> > > >> >
> > > >> > This could be a *win-win* for all of us, allowing contributors to
> > > provide
> > > >> > high quality code, and reducing the burden on committers to
> provide
> > > >> > individual feedback about the code style practices and standards
> > that
> > > are
> > > >> > currently applied in the Cordova source code.
> > > >> >
> > > >> > For contributors following these style guidelines, their code it
> > will
> > > be
> > > >> > easier to review and merge into the project quickly.
> > > >> >
> > > >> > Well, that's the proposal that I have, if you are agree with it,
> > > please
> > > >> > check the few lines that I've added to the Style guide page, and
> > feel
> > > >> > yourself free to add more information, comments, practices,
> > > >> > recommendations, modify the current ones, whatever that you can
> > > provide
> > > >> it
> > > >> > would be great.
> > > >> >
> > > >> > If you don't have permission to add information the Wiki page, you
> > can
> > > >> ask
> > > >> > to a commiter for access to it. Or you can share a replay with the
> > > >> > information that you'd like to add, and I'll be happy to post it.
> > > >> >
> > > >> > Thanks.
> > > >> > -Martin
> > > >> >
> > > >>
> > >
> >
>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Joe Bowser <bo...@gmail.com>.
Can we have that magic git setting that fixes Windows carriage returns
recorded in here? That'd be awesome.
On Wed, Apr 23, 2014 at 2:29 PM, Martin Gonzalez Glez
<ma...@gmail.com> wrote:
> Yes, we have to get to an agreement on that, and of course, we have to
> follow the current style, I'm not proposing create a new style or follow
> another style or pattern.
> The whole listed items in Style Guide, are part of the feedback that so
> far, I have received from commiters. What I was trying to point here, is
> encourage the whole community to describe Cordova practices based on the
> current code, on the current style, for those new contributors involved
> with code deliverance.
>
> Of course Jesse, we should discuss this and get to an agreement, for all of
> us follow those same guidelines.
>
> Thought: If Jesse reviews a contributor's PR, he surely will get some
> feedback and guidance from Jesse, the contributor would think that based on
> those practices that he learned from Jesse, it's the best way, the current
> Code style. But maybe in another PR, Andrew reviews his code, he may point
> to change some of the practices that he learn from Jesse. That may happen.
> I'm not trying that everybody think in the same way, about how to create
> logic. Just trying to set an starting point to explicitely describe, which
> is the pattern of code style that we are using, in that way everyone is
> going to be in the same page since the very beginning.
>
>
>
> 2014-04-23 15:35 GMT-05:00 Jesse <pu...@gmail.com>:
>
>> I agree with Andrew, there are several items in the style guide that I
>> question.
>> But mainly I question how a definitive guide can be defined without
>> agreement ...
>>
>>
>>
>>
>> @purplecabbage
>> risingj.com
>>
>>
>> On Wed, Apr 23, 2014 at 1:30 PM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>>
>> > In general, I think the only style guideline we need (at least for a
>> > non-per-repo sense), is to follow whatever style currently exists.
>> >
>> > On Wed, Apr 23, 2014 at 4:25 PM, Mark Koudritsky <ka...@google.com>
>> > wrote:
>> > > The style guide contains the following two points that seem to
>> partially
>> > > contradict each other. Ok if we just delete the second one?
>> > >
>> > > 1. Remove unnecessary trailing whitespace in lines; this includes
>> > after
>> > > operators, commas, semicolons or braces.
>> > > 2. trailing spaces - you should turn off "remove trailing spaces" in
>> > > your editor/IDE. That is, trailing spaces should be left in files.
>> Not
>> > > doing this yields extra diff junk, and sometime trailing spaces are
>> > > significant.
>> > >
>> > >
>> > >
>> > > On Wed, Apr 23, 2014 at 2:41 PM, Shazron <sh...@gmail.com> wrote:
>> > >
>> > >> I'll add this to the wiki, but putting it out here as well for the
>> other
>> > >> platforms/plugins:
>> > >>
>> > >> cordova-ios uses uncrustify in a pre-commit hook:
>> > >> https://github.com/apache/cordova-ios/tree/master/hooks that needs to
>> > be
>> > >> added on a per clone basis. Saves me a lot of time when I do my own
>> > >> commits. It can be configured for other languages. Could be a coho
>> > thing to
>> > >> add these hooks when pulling down repos (gasp) ;)
>> > >>
>> > >> Also, regarding contributing, I added this issue for adding a
>> > >> CONTRIBUTING.md to all our repos:
>> > >> https://issues.apache.org/jira/browse/CB-6491
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> On Wed, Apr 23, 2014 at 11:23 AM, Martin Gonzalez Glez <
>> > >> martin.c.glez.glez@gmail.com> wrote:
>> > >>
>> > >> > Hi guys,
>> > >> >
>> > >> > As code contributor, I've been receiving feedback, comments, advice
>> > and
>> > >> > more from the commiters. Part of the received feedback is about the
>> > >> Cordova
>> > >> > code style, best practices, and
>> > >> > preferences about how to contribute code to the project, which
>> > existing
>> > >> > APIs to use, and more.
>> > >> >
>> > >> > Because of that, I have added some advices about code style,
>> practices
>> > >> and
>> > >> > preferences in the wiki page:
>> > >> >
>> > >> > https://wiki.apache.org/cordova/StyleGuide
>> > >> >
>> > >> > This kind of information it would be great for new Contributors
>> > involved
>> > >> in
>> > >> > code deliverance, to serve as initial guidance to follow.
>> > >> >
>> > >> > That said, I have a *proposal *for all of you guys if are agree.
>> > >> > It's about adding this wiki page as part of the
>> *ContributorWorkflow*;
>> > >> the
>> > >> > content attempts to explain basic styles, patterns, practices, and
>> > >> methods
>> > >> > used in the project. All new and existent code should conform to
>> these
>> > >> > guidelines in order to maintain structural quality and code
>> > readability,
>> > >> > and to make software maintenance easier.
>> > >> >
>> > >> > This could be a *win-win* for all of us, allowing contributors to
>> > provide
>> > >> > high quality code, and reducing the burden on committers to provide
>> > >> > individual feedback about the code style practices and standards
>> that
>> > are
>> > >> > currently applied in the Cordova source code.
>> > >> >
>> > >> > For contributors following these style guidelines, their code it
>> will
>> > be
>> > >> > easier to review and merge into the project quickly.
>> > >> >
>> > >> > Well, that's the proposal that I have, if you are agree with it,
>> > please
>> > >> > check the few lines that I've added to the Style guide page, and
>> feel
>> > >> > yourself free to add more information, comments, practices,
>> > >> > recommendations, modify the current ones, whatever that you can
>> > provide
>> > >> it
>> > >> > would be great.
>> > >> >
>> > >> > If you don't have permission to add information the Wiki page, you
>> can
>> > >> ask
>> > >> > to a commiter for access to it. Or you can share a replay with the
>> > >> > information that you'd like to add, and I'll be happy to post it.
>> > >> >
>> > >> > Thanks.
>> > >> > -Martin
>> > >> >
>> > >>
>> >
>>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Martin Gonzalez Glez <ma...@gmail.com>.
Yes, we have to get to an agreement on that, and of course, we have to
follow the current style, I'm not proposing create a new style or follow
another style or pattern.
The whole listed items in Style Guide, are part of the feedback that so
far, I have received from commiters. What I was trying to point here, is
encourage the whole community to describe Cordova practices based on the
current code, on the current style, for those new contributors involved
with code deliverance.
Of course Jesse, we should discuss this and get to an agreement, for all of
us follow those same guidelines.
Thought: If Jesse reviews a contributor's PR, he surely will get some
feedback and guidance from Jesse, the contributor would think that based on
those practices that he learned from Jesse, it's the best way, the current
Code style. But maybe in another PR, Andrew reviews his code, he may point
to change some of the practices that he learn from Jesse. That may happen.
I'm not trying that everybody think in the same way, about how to create
logic. Just trying to set an starting point to explicitely describe, which
is the pattern of code style that we are using, in that way everyone is
going to be in the same page since the very beginning.
2014-04-23 15:35 GMT-05:00 Jesse <pu...@gmail.com>:
> I agree with Andrew, there are several items in the style guide that I
> question.
> But mainly I question how a definitive guide can be defined without
> agreement ...
>
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Wed, Apr 23, 2014 at 1:30 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > In general, I think the only style guideline we need (at least for a
> > non-per-repo sense), is to follow whatever style currently exists.
> >
> > On Wed, Apr 23, 2014 at 4:25 PM, Mark Koudritsky <ka...@google.com>
> > wrote:
> > > The style guide contains the following two points that seem to
> partially
> > > contradict each other. Ok if we just delete the second one?
> > >
> > > 1. Remove unnecessary trailing whitespace in lines; this includes
> > after
> > > operators, commas, semicolons or braces.
> > > 2. trailing spaces - you should turn off "remove trailing spaces" in
> > > your editor/IDE. That is, trailing spaces should be left in files.
> Not
> > > doing this yields extra diff junk, and sometime trailing spaces are
> > > significant.
> > >
> > >
> > >
> > > On Wed, Apr 23, 2014 at 2:41 PM, Shazron <sh...@gmail.com> wrote:
> > >
> > >> I'll add this to the wiki, but putting it out here as well for the
> other
> > >> platforms/plugins:
> > >>
> > >> cordova-ios uses uncrustify in a pre-commit hook:
> > >> https://github.com/apache/cordova-ios/tree/master/hooks that needs to
> > be
> > >> added on a per clone basis. Saves me a lot of time when I do my own
> > >> commits. It can be configured for other languages. Could be a coho
> > thing to
> > >> add these hooks when pulling down repos (gasp) ;)
> > >>
> > >> Also, regarding contributing, I added this issue for adding a
> > >> CONTRIBUTING.md to all our repos:
> > >> https://issues.apache.org/jira/browse/CB-6491
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Wed, Apr 23, 2014 at 11:23 AM, Martin Gonzalez Glez <
> > >> martin.c.glez.glez@gmail.com> wrote:
> > >>
> > >> > Hi guys,
> > >> >
> > >> > As code contributor, I've been receiving feedback, comments, advice
> > and
> > >> > more from the commiters. Part of the received feedback is about the
> > >> Cordova
> > >> > code style, best practices, and
> > >> > preferences about how to contribute code to the project, which
> > existing
> > >> > APIs to use, and more.
> > >> >
> > >> > Because of that, I have added some advices about code style,
> practices
> > >> and
> > >> > preferences in the wiki page:
> > >> >
> > >> > https://wiki.apache.org/cordova/StyleGuide
> > >> >
> > >> > This kind of information it would be great for new Contributors
> > involved
> > >> in
> > >> > code deliverance, to serve as initial guidance to follow.
> > >> >
> > >> > That said, I have a *proposal *for all of you guys if are agree.
> > >> > It's about adding this wiki page as part of the
> *ContributorWorkflow*;
> > >> the
> > >> > content attempts to explain basic styles, patterns, practices, and
> > >> methods
> > >> > used in the project. All new and existent code should conform to
> these
> > >> > guidelines in order to maintain structural quality and code
> > readability,
> > >> > and to make software maintenance easier.
> > >> >
> > >> > This could be a *win-win* for all of us, allowing contributors to
> > provide
> > >> > high quality code, and reducing the burden on committers to provide
> > >> > individual feedback about the code style practices and standards
> that
> > are
> > >> > currently applied in the Cordova source code.
> > >> >
> > >> > For contributors following these style guidelines, their code it
> will
> > be
> > >> > easier to review and merge into the project quickly.
> > >> >
> > >> > Well, that's the proposal that I have, if you are agree with it,
> > please
> > >> > check the few lines that I've added to the Style guide page, and
> feel
> > >> > yourself free to add more information, comments, practices,
> > >> > recommendations, modify the current ones, whatever that you can
> > provide
> > >> it
> > >> > would be great.
> > >> >
> > >> > If you don't have permission to add information the Wiki page, you
> can
> > >> ask
> > >> > to a commiter for access to it. Or you can share a replay with the
> > >> > information that you'd like to add, and I'll be happy to post it.
> > >> >
> > >> > Thanks.
> > >> > -Martin
> > >> >
> > >>
> >
>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Jesse <pu...@gmail.com>.
I agree with Andrew, there are several items in the style guide that I
question.
But mainly I question how a definitive guide can be defined without
agreement ...
@purplecabbage
risingj.com
On Wed, Apr 23, 2014 at 1:30 PM, Andrew Grieve <ag...@chromium.org> wrote:
> In general, I think the only style guideline we need (at least for a
> non-per-repo sense), is to follow whatever style currently exists.
>
> On Wed, Apr 23, 2014 at 4:25 PM, Mark Koudritsky <ka...@google.com>
> wrote:
> > The style guide contains the following two points that seem to partially
> > contradict each other. Ok if we just delete the second one?
> >
> > 1. Remove unnecessary trailing whitespace in lines; this includes
> after
> > operators, commas, semicolons or braces.
> > 2. trailing spaces - you should turn off "remove trailing spaces" in
> > your editor/IDE. That is, trailing spaces should be left in files. Not
> > doing this yields extra diff junk, and sometime trailing spaces are
> > significant.
> >
> >
> >
> > On Wed, Apr 23, 2014 at 2:41 PM, Shazron <sh...@gmail.com> wrote:
> >
> >> I'll add this to the wiki, but putting it out here as well for the other
> >> platforms/plugins:
> >>
> >> cordova-ios uses uncrustify in a pre-commit hook:
> >> https://github.com/apache/cordova-ios/tree/master/hooks that needs to
> be
> >> added on a per clone basis. Saves me a lot of time when I do my own
> >> commits. It can be configured for other languages. Could be a coho
> thing to
> >> add these hooks when pulling down repos (gasp) ;)
> >>
> >> Also, regarding contributing, I added this issue for adding a
> >> CONTRIBUTING.md to all our repos:
> >> https://issues.apache.org/jira/browse/CB-6491
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Apr 23, 2014 at 11:23 AM, Martin Gonzalez Glez <
> >> martin.c.glez.glez@gmail.com> wrote:
> >>
> >> > Hi guys,
> >> >
> >> > As code contributor, I've been receiving feedback, comments, advice
> and
> >> > more from the commiters. Part of the received feedback is about the
> >> Cordova
> >> > code style, best practices, and
> >> > preferences about how to contribute code to the project, which
> existing
> >> > APIs to use, and more.
> >> >
> >> > Because of that, I have added some advices about code style, practices
> >> and
> >> > preferences in the wiki page:
> >> >
> >> > https://wiki.apache.org/cordova/StyleGuide
> >> >
> >> > This kind of information it would be great for new Contributors
> involved
> >> in
> >> > code deliverance, to serve as initial guidance to follow.
> >> >
> >> > That said, I have a *proposal *for all of you guys if are agree.
> >> > It's about adding this wiki page as part of the *ContributorWorkflow*;
> >> the
> >> > content attempts to explain basic styles, patterns, practices, and
> >> methods
> >> > used in the project. All new and existent code should conform to these
> >> > guidelines in order to maintain structural quality and code
> readability,
> >> > and to make software maintenance easier.
> >> >
> >> > This could be a *win-win* for all of us, allowing contributors to
> provide
> >> > high quality code, and reducing the burden on committers to provide
> >> > individual feedback about the code style practices and standards that
> are
> >> > currently applied in the Cordova source code.
> >> >
> >> > For contributors following these style guidelines, their code it will
> be
> >> > easier to review and merge into the project quickly.
> >> >
> >> > Well, that's the proposal that I have, if you are agree with it,
> please
> >> > check the few lines that I've added to the Style guide page, and feel
> >> > yourself free to add more information, comments, practices,
> >> > recommendations, modify the current ones, whatever that you can
> provide
> >> it
> >> > would be great.
> >> >
> >> > If you don't have permission to add information the Wiki page, you can
> >> ask
> >> > to a commiter for access to it. Or you can share a replay with the
> >> > information that you'd like to add, and I'll be happy to post it.
> >> >
> >> > Thanks.
> >> > -Martin
> >> >
> >>
>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Andrew Grieve <ag...@chromium.org>.
In general, I think the only style guideline we need (at least for a
non-per-repo sense), is to follow whatever style currently exists.
On Wed, Apr 23, 2014 at 4:25 PM, Mark Koudritsky <ka...@google.com> wrote:
> The style guide contains the following two points that seem to partially
> contradict each other. Ok if we just delete the second one?
>
> 1. Remove unnecessary trailing whitespace in lines; this includes after
> operators, commas, semicolons or braces.
> 2. trailing spaces - you should turn off "remove trailing spaces" in
> your editor/IDE. That is, trailing spaces should be left in files. Not
> doing this yields extra diff junk, and sometime trailing spaces are
> significant.
>
>
>
> On Wed, Apr 23, 2014 at 2:41 PM, Shazron <sh...@gmail.com> wrote:
>
>> I'll add this to the wiki, but putting it out here as well for the other
>> platforms/plugins:
>>
>> cordova-ios uses uncrustify in a pre-commit hook:
>> https://github.com/apache/cordova-ios/tree/master/hooks that needs to be
>> added on a per clone basis. Saves me a lot of time when I do my own
>> commits. It can be configured for other languages. Could be a coho thing to
>> add these hooks when pulling down repos (gasp) ;)
>>
>> Also, regarding contributing, I added this issue for adding a
>> CONTRIBUTING.md to all our repos:
>> https://issues.apache.org/jira/browse/CB-6491
>>
>>
>>
>>
>>
>> On Wed, Apr 23, 2014 at 11:23 AM, Martin Gonzalez Glez <
>> martin.c.glez.glez@gmail.com> wrote:
>>
>> > Hi guys,
>> >
>> > As code contributor, I've been receiving feedback, comments, advice and
>> > more from the commiters. Part of the received feedback is about the
>> Cordova
>> > code style, best practices, and
>> > preferences about how to contribute code to the project, which existing
>> > APIs to use, and more.
>> >
>> > Because of that, I have added some advices about code style, practices
>> and
>> > preferences in the wiki page:
>> >
>> > https://wiki.apache.org/cordova/StyleGuide
>> >
>> > This kind of information it would be great for new Contributors involved
>> in
>> > code deliverance, to serve as initial guidance to follow.
>> >
>> > That said, I have a *proposal *for all of you guys if are agree.
>> > It's about adding this wiki page as part of the *ContributorWorkflow*;
>> the
>> > content attempts to explain basic styles, patterns, practices, and
>> methods
>> > used in the project. All new and existent code should conform to these
>> > guidelines in order to maintain structural quality and code readability,
>> > and to make software maintenance easier.
>> >
>> > This could be a *win-win* for all of us, allowing contributors to provide
>> > high quality code, and reducing the burden on committers to provide
>> > individual feedback about the code style practices and standards that are
>> > currently applied in the Cordova source code.
>> >
>> > For contributors following these style guidelines, their code it will be
>> > easier to review and merge into the project quickly.
>> >
>> > Well, that's the proposal that I have, if you are agree with it, please
>> > check the few lines that I've added to the Style guide page, and feel
>> > yourself free to add more information, comments, practices,
>> > recommendations, modify the current ones, whatever that you can provide
>> it
>> > would be great.
>> >
>> > If you don't have permission to add information the Wiki page, you can
>> ask
>> > to a commiter for access to it. Or you can share a replay with the
>> > information that you'd like to add, and I'll be happy to post it.
>> >
>> > Thanks.
>> > -Martin
>> >
>>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Mark Koudritsky <ka...@google.com>.
The style guide contains the following two points that seem to partially
contradict each other. Ok if we just delete the second one?
1. Remove unnecessary trailing whitespace in lines; this includes after
operators, commas, semicolons or braces.
2. trailing spaces - you should turn off "remove trailing spaces" in
your editor/IDE. That is, trailing spaces should be left in files. Not
doing this yields extra diff junk, and sometime trailing spaces are
significant.
On Wed, Apr 23, 2014 at 2:41 PM, Shazron <sh...@gmail.com> wrote:
> I'll add this to the wiki, but putting it out here as well for the other
> platforms/plugins:
>
> cordova-ios uses uncrustify in a pre-commit hook:
> https://github.com/apache/cordova-ios/tree/master/hooks that needs to be
> added on a per clone basis. Saves me a lot of time when I do my own
> commits. It can be configured for other languages. Could be a coho thing to
> add these hooks when pulling down repos (gasp) ;)
>
> Also, regarding contributing, I added this issue for adding a
> CONTRIBUTING.md to all our repos:
> https://issues.apache.org/jira/browse/CB-6491
>
>
>
>
>
> On Wed, Apr 23, 2014 at 11:23 AM, Martin Gonzalez Glez <
> martin.c.glez.glez@gmail.com> wrote:
>
> > Hi guys,
> >
> > As code contributor, I've been receiving feedback, comments, advice and
> > more from the commiters. Part of the received feedback is about the
> Cordova
> > code style, best practices, and
> > preferences about how to contribute code to the project, which existing
> > APIs to use, and more.
> >
> > Because of that, I have added some advices about code style, practices
> and
> > preferences in the wiki page:
> >
> > https://wiki.apache.org/cordova/StyleGuide
> >
> > This kind of information it would be great for new Contributors involved
> in
> > code deliverance, to serve as initial guidance to follow.
> >
> > That said, I have a *proposal *for all of you guys if are agree.
> > It's about adding this wiki page as part of the *ContributorWorkflow*;
> the
> > content attempts to explain basic styles, patterns, practices, and
> methods
> > used in the project. All new and existent code should conform to these
> > guidelines in order to maintain structural quality and code readability,
> > and to make software maintenance easier.
> >
> > This could be a *win-win* for all of us, allowing contributors to provide
> > high quality code, and reducing the burden on committers to provide
> > individual feedback about the code style practices and standards that are
> > currently applied in the Cordova source code.
> >
> > For contributors following these style guidelines, their code it will be
> > easier to review and merge into the project quickly.
> >
> > Well, that's the proposal that I have, if you are agree with it, please
> > check the few lines that I've added to the Style guide page, and feel
> > yourself free to add more information, comments, practices,
> > recommendations, modify the current ones, whatever that you can provide
> it
> > would be great.
> >
> > If you don't have permission to add information the Wiki page, you can
> ask
> > to a commiter for access to it. Or you can share a replay with the
> > information that you'd like to add, and I'll be happy to post it.
> >
> > Thanks.
> > -Martin
> >
>
Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Posted by Shazron <sh...@gmail.com>.
I'll add this to the wiki, but putting it out here as well for the other
platforms/plugins:
cordova-ios uses uncrustify in a pre-commit hook:
https://github.com/apache/cordova-ios/tree/master/hooks that needs to be
added on a per clone basis. Saves me a lot of time when I do my own
commits. It can be configured for other languages. Could be a coho thing to
add these hooks when pulling down repos (gasp) ;)
Also, regarding contributing, I added this issue for adding a
CONTRIBUTING.md to all our repos:
https://issues.apache.org/jira/browse/CB-6491
On Wed, Apr 23, 2014 at 11:23 AM, Martin Gonzalez Glez <
martin.c.glez.glez@gmail.com> wrote:
> Hi guys,
>
> As code contributor, I've been receiving feedback, comments, advice and
> more from the commiters. Part of the received feedback is about the Cordova
> code style, best practices, and
> preferences about how to contribute code to the project, which existing
> APIs to use, and more.
>
> Because of that, I have added some advices about code style, practices and
> preferences in the wiki page:
>
> https://wiki.apache.org/cordova/StyleGuide
>
> This kind of information it would be great for new Contributors involved in
> code deliverance, to serve as initial guidance to follow.
>
> That said, I have a *proposal *for all of you guys if are agree.
> It's about adding this wiki page as part of the *ContributorWorkflow*; the
> content attempts to explain basic styles, patterns, practices, and methods
> used in the project. All new and existent code should conform to these
> guidelines in order to maintain structural quality and code readability,
> and to make software maintenance easier.
>
> This could be a *win-win* for all of us, allowing contributors to provide
> high quality code, and reducing the burden on committers to provide
> individual feedback about the code style practices and standards that are
> currently applied in the Cordova source code.
>
> For contributors following these style guidelines, their code it will be
> easier to review and merge into the project quickly.
>
> Well, that's the proposal that I have, if you are agree with it, please
> check the few lines that I've added to the Style guide page, and feel
> yourself free to add more information, comments, practices,
> recommendations, modify the current ones, whatever that you can provide it
> would be great.
>
> If you don't have permission to add information the Wiki page, you can ask
> to a commiter for access to it. Or you can share a replay with the
> information that you'd like to add, and I'll be happy to post it.
>
> Thanks.
> -Martin
>