I have to say.....I totally agree with Kanstantsin. We need a coding style guide. I like how Netty project is managing this, using Checkstyle: https://github.com/netty/netty-build/blob/master/pom.xml#L69
Regards, 2015-10-27 9:30 GMT+01:00 Baptiste Mathus <[email protected]>: > Btw, I just remembered I already provide the xml export for my plugin: > https://github.com/jenkinsci/buildtriggerbadge-plugin/blob/master/buildtriggerbadge-eclipse-formatter-profile.xml > and ask contributors to try and follow it: > https://github.com/jenkinsci/buildtriggerbadge-plugin#contributing though I > neither enforce nor actively check formatting in PRs currently. > > Cheers > > 2015-10-27 9:28 GMT+01:00 Baptiste Mathus <[email protected]>: >> >> +0.9 though I agree this is generally a subject many people love to >> disagree on. I prefer having an automated codestyle people can just import >> into their IDE and just apply before committing/at save. >> >> For example, the Maven dev team provides an xml export of the formatting >> rules for Eclipse[1], and I've used it in the past to contribute. >> Contrary to what some people seem to think, I actually liked and still >> like it: IMO it makes it easier for newcomers to contribute. >> >> Personnally my main side-concern (apart from the code itself I mean) when >> first contributing to an OSS project is respecting its rules. >> Having an automated formatter available makes that part a no-brainer and >> ppl can concentrate on the real issues. >> >> As for the rare cases where you want to manually format code for the sake >> of readability for whatever reasons, every formaters out there generally >> support tags to disable/reenable automated formated locally [2]. >> >> [1] https://maven.apache.org/developers/conventions/code.html#Eclipse_3.2 >> [2] example with Eclipse >> http://batmat.github.io/presentations/50-slides-of-ide/prez.html#formatterOnOff >> >> 2015-10-27 8:05 GMT+01:00 domi <[email protected]>: >>> >>> I think formatting is a must and I would have loved to have such rules >>> when I started to work on jenkins some years ago. Personally I think that >>> the longer we wait to introduce this, the more it will hurt. >>> I’m happy to volunteer in the adoption of such formatting rules for my >>> plugins - but I would love to have them defined in a central place. >>> Domi >>> >>> >>> >>> On 26 Oct 2015, at 23:53, Mark Waite <[email protected]> wrote: >>> >>> >>> >>> On Mon, Oct 26, 2015 at 4:24 PM Nigel Magnay <[email protected]> >>> wrote: >>>>> >>>>> Both will be acceptable in styling. That lines are about logic that >>>>> analysing tool can’t know. >>>> >>>> >>>> Bingo. >>>> >>>> "Automatic code formatters" don't know the semantics of what they're >>>> formatting, so you apply them end up with gigantic concatented lines >>>> (sometimes split to 80 columns, as if we're still producing punched cards). >>>> >>>> This is clearly worse than the "unformatted" case - where the author has >>>> carefully aided the maintainer by splitting on semantically distinct >>>> sections. >>>> >>>> By all means, have some IDE defaults that can be picked up (e.g: spaces >>>> or tabs, tabstops, whether to use '*' imports or not), but auto-code >>>> formatters are evil. >>> >>> >>> >>> You describe things with a very broad brush. Earlier you extrapolated >>> from a request to format code into a comment about management measuring the >>> irrelevant. Now you're declaring that the benefits my team of 10+ (using >>> extreme programming as our methodology, pair programming everything, test >>> driven development, etc.) found from automated code formatting over multiple >>> years of working together should be ignored because "auto-code formatters >>> are evil". The sole specific example you offer is that calls to fluent >>> API's aren't we'll preserved by automatic code formatters. >>> >>> Can you offer other concrete examples of cases (preferably in the >>> existing code) where an automatic formatter will have a serious negative >>> impact? >>> >>> When I look at the git-client-plugin source code, I find relatively few >>> cases of the fluent calls being badly damaged by an automatic formatter. >>> There are many fluent calls, but most of them will be untouched by an >>> automatic formatter. >>> >>> There is a trade-off between the simplicity of automatically maintained >>> code format (with occasional sub-optimal formatting as a result of the >>> automation) and the work I must do on every pull request to not make code >>> formatting consistency worse in the two plugins I maintain. >>> >>> I only maintain two plugins of the 1000+, so I accept that I should not >>> be considered as a major influence in the final decision. >>> >>> Mark Waite >>> >>>> >>>> >>>>> >>>>> or >>>>> periodFormatter = new >>>>> PeriodFormatterBuilder().printZeroAlways().appendDays().appendSuffix("d >>>>> ").appendHours().appendSuffix("h ") >>>>> .appendMinutes().appendSuffix("m").toFormatter(); >>>>> <——— scroll ——----> >>>>> >>>>> P.S. Am i alone who receives emails from Nigel with small blue font? >>>> >>>> >>>> >>>>> On Oct 27, 2015, at 01:02, Nigel Magnay <[email protected]> wrote: >>>>> >>>>> You don't need to trial automatic code formatting it to know it's going >>>>> to produce a terrible result. >>>>> >>>>> Trivial example 101. Which is the more easily parseable to the human >>>>> eye? >>>>> >>>>> periodFormatter = new PeriodFormatterBuilder() >>>>> .printZeroAlways() >>>>> .appendDays().appendSuffix("d ") >>>>> .appendHours().appendSuffix("h ") >>>>> .appendMinutes().appendSuffix("m") >>>>> .toFormatter(); >>>>> >>>>> or >>>>> >>>>> periodFormatter = new >>>>> PeriodFormatterBuilder().printZeroAlways().appendDays() >>>>> .appendSuffix("d >>>>> ").appendHours().appendSuffix("h ") >>>>> >>>>> .appendMinutes().appendSuffix("m").toFormatter(); >>>>> >>>>> >>>>> I know which I'd rather be faced with when maintaining code. >>>>> >>>>> On Mon, Oct 26, 2015 at 9:55 PM, Mark Waite <[email protected]> >>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Oct 26, 2015 at 1:21 PM Stephen Connolly >>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> I think that the best way to do this is via an experiment in >>>>>>> plugins... If we get a critical mass of plugins adopting a mostly >>>>>>> similar >>>>>>> set of rules then and only then should we think about applying them to >>>>>>> core >>>>>>> >>>>>> >>>>>> I volunteer to experiment with a branch of the git client plugin as a >>>>>> first candidate. I'd limit the formatting to newer files and files that >>>>>> I've created myself so that the "diff wall" won't be as difficult. Older >>>>>> files with wildly divergent formatting styles will remain that way as >>>>>> part >>>>>> of the first phase of the experiment. >>>>>> >>>>>> That will give a chance to evaluate Nigel's concern for the impact on >>>>>> fluent API calls (since there are several fluent interfaces in the git >>>>>> client plugin). >>>>>> >>>>>> Mark Waite >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Jenkins Developers" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>>> an email to [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHbxMpH1RTwRMiYuDj71pVi1fTSsUFbHTpEh%3DeYGMNezg%40mail.gmail.com. >>>>>> >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "Jenkins Developers" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/d/topic/jenkinsci-dev/8fjvXGYbFJ4/unsubscribe. >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83TJO306gyDmEt_fVx88XVZK54gK7O3JhxqSFzDgLrn6Xg%40mail.gmail.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Jenkins Developers" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/jenkinsci-dev/FF20FA21-AF8B-46EE-B8DF-10A9DEBA8921%40gmail.com. >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Jenkins Developers" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83Q73VNYKWJWX2iP_0QA9z%3Dy%3DpbDPBHMy0tQJ%2BX6Ley1Ng%40mail.gmail.com. >>>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Jenkins Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHxPmXuDzResjM2PZx04p94khB55O2n4auEoUf9wdY_sA%40mail.gmail.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Jenkins Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jenkinsci-dev/D7807A3C-0F85-4CD8-A1DB-6E907B2CCA90%40fortysix.ch. >>> >>> For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> -- >> Baptiste <Batmat> MATHUS - http://batmat.net >> Sauvez un arbre, >> Mangez un castor ! > > > > > -- > Baptiste <Batmat> MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7L3tJr8yfA_jYKu6gbvpJ7XAW2kOWAwB8ja_DO1OrOhg%40mail.gmail.com. > > For more options, visit https://groups.google.com/d/optout. -- Manuel Recena Soto * manuelrecena.com [/blog] * linkedin.com/in/recena -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CABa-UodqWeW8TB2Tsoicibs3QCX3pMbWHkpmgUoFYD6ZxuXjBg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
