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