cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Koudritsky <kam...@google.com>
Subject Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Date Wed, 23 Apr 2014 22:13:07 GMT
+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 <purplecabbage@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 <shazron@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
> > > > >> >
> > > > >>
> > > >
> > >
> >
>

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