cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: [Proposal] Cordova guidelines part of ContributorWorkflow
Date Thu, 24 Apr 2014 01:48:19 GMT
+1 for jshint.


On Wed, Apr 23, 2014 at 5:53 PM, Andrew Grieve <agrieve@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 <kamrik@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 <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