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.g...@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 <purplecabb...@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 <agri...@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 <kam...@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 <shaz...@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.g...@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
> > > >> >
> > > >>
> > >
> >
>

Reply via email to