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.
For more options, visit https://groups.google.com/d/optout.
