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 >>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHbxMpH1RTwRMiYuDj71pVi1fTSsUFbHTpEh%3DeYGMNezg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> 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 >>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83TJO306gyDmEt_fVx88XVZK54gK7O3JhxqSFzDgLrn6Xg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> 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 >>>> <https://groups.google.com/d/msgid/jenkinsci-dev/FF20FA21-AF8B-46EE-B8DF-10A9DEBA8921%40gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> 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 >>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83Q73VNYKWJWX2iP_0QA9z%3Dy%3DpbDPBHMy0tQJ%2BX6Ley1Ng%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> 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 >> <https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHxPmXuDzResjM2PZx04p94khB55O2n4auEoUf9wdY_sA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> 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 >> <https://groups.google.com/d/msgid/jenkinsci-dev/D7807A3C-0F85-4CD8-A1DB-6E907B2CCA90%40fortysix.ch?utm_medium=email&utm_source=footer> >> . >> >> 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.
