+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 ! -- 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/CANWgJS4ZsQ4hOy%2BHZEKDHDpWqy%2B2GdqxXCJBkLv2hDx5_AZjKA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
