Personally, I'm not a fan of the shared git hooks suggestion. I would be all for them, if they ran by default without installation. However, I cannot see the average user reading the documentation to properly install the hooks, and I don't want git hooks to become an contribution barrier.
I would rather: - lead by example with clean code [1] - use common/bundled code syntax checkers (e.g. JSHint [2][3], Eclipse's project formatting XML [4], etc) - deny pull requests that are poorly formatted and educate the contributor on what needs to be corrected - publicly shame committers (in a nice manner) who consistently push code that breaks the file's (lenient) code conventions (e.g. spaces/tabs, trailing whitespace, braces on the proper line, etc) [1] http://wiki.apache.org/cordova/StyleGuide [2] https://github.com/apache/incubator-cordova-js/blob/master/Jakefile#L60 [3] https://github.com/apache/incubator-cordova-js/blob/master/.jshintrc [4] https://github.com/android/platform_development/tree/master/ide/eclipse On Mon, Aug 27, 2012 at 8:19 AM, Filip Maj <[email protected]> wrote: > Just some extra stuff on the topic: > > - There is a style guide on the wiki (although it _does_ need to be filled > out): http://wiki.apache.org/cordova/StyleGuide > - cordova-js already has something like this (jshint via a "hint" task [1] > with config at [2]) but it's hooked in at build-time instead of when > committing. > > [1] > https://github.com/apache/incubator-cordova-js/blob/master/Jakefile#L60 > [2] https://github.com/apache/incubator-cordova-js/blob/master/.jshintrc > > On 8/27/12 7:53 AM, "Simon MacDonald" <[email protected]> wrote: > > >For those of us on Android using Eclipse we could standardize on: > > > >https://github.com/android/platform_development/tree/master/ide/eclipse > > > >Simon Mac Donald > >http://hi.im/simonmacdonald > > > > > >On Mon, Aug 27, 2012 at 10:33 AM, Andrew Grieve > ><[email protected]>wrote: > > > >> From the threads in the past on this subject, it seems like: > >> > >> -Style is an opinion, but: > >> -A consistent style would be nice even if it's not everyone's preference > >> -We don't want to shy away contributors by annoying them with style > >> concerns > >> > >> I think we could get some value out of using a command-line code > >>prettifier > >> and shared git hooks. The flow I'm envisioning here is: > >> > >> $ git commit ... > >> // git hooks complain about your style and tell you to run fix_style > >> $ bin/fix_style > >> $ git diff // Shows you what the reformatter did to you. > >> $ git add ... > >> $ git commit // passes the style check. > >> > >> > >> So: > >> 1. We should never have to complain about style when looking at pull > >> requests > >> 2. We should get a consistent style > >> 3. In the least, I'd like to see consistent tabs v spaces & no trailing > >>ws. > >> > >> One thing we may have to do is ask a contributor to enable the git > >>hooks. > >> AFAIK there is no way to enable shared git hooks for a project by > >>default, > >> so what we'd have is a directory called "hooks" and you'd need to > >>create a > >> symlink for it into your .git/ directory. > >> > >> If no one objects, then I'll pursue this today/tomorrow. My plan is to > >> start with whitespace (sed or awk), get that working, and then see what > >> x-platform open-source formatters exist out there. > >> > >> Andrew > >> > >
