incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Brooks <mich...@michaelbrooks.ca>
Subject Re: Code Prettifiers
Date Mon, 27 Aug 2012 17:11:45 GMT
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 <fil@adobe.com> 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" <simon.macdonald@gmail.com> 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
> ><agrieve@chromium.org>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
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message