+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 <[email protected]> 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 < > [email protected]> 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 <[email protected]>: > > > > > 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 <[email protected]> > > > 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 <[email protected]> > > > > 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 <[email protected]> > 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 < > > > > >> [email protected]> 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 > > > > >> > > > > > >> > > > > > > > > > >
