>
>
>
>
> 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?
>
>
I still struggle to see the purported benefit. It feels like a collective
delusion - that we've carried forward an idea from the PL/1 and FORTRAN era
(where, for example, long lines are particularly bad because soft-wrapping
editors don't exist) because it somehow 'feels right'. "Nicely formatted
code is a benefit... because formatted code is nice". Like much in software
engineering, we sleepwalk into things because it seems to be what other
people are doing (appeal to authority) or out of fear that 'you can't be
considered a professional unless you're doing X', or that we have no way of
demonstrating Quality, so we substitute Consistency in its place and hope
nobody notices.
The example I gave is hardly conjured-up. Fluent APIs are all over the
place. Here's a docker-plugin example
String tag_image = client.commitCmd(containerId)
.withRepository(theRun.getParent().getDisplayName())
.withTag(theRun.getDisplayName().replace("#", "b"))
.withAuthor("Jenkins")
.exec();
becomes
String tag_image =
client.commitCmd(containerId).withRepository(theRun.getParent().getDisplayName())
.withTag(theRun.getDisplayName().replace("#",
"b")).withAuthor("Jenkins").exec();
So I find the 'benefit' of a formatter - for example - caring about the
number of spaces after an open-bracket vs the semantic destruction above to
be Very Bad Tradeoff, so people end up adding horrific comment-cruft to
coerce their formatter into doing 'the right thing' without ever pausing to
challenge the actual claimed benefit in the first place.
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.
>
>
That is only a tradeoff *if* you care about the format (being
'ultra-consistent'), and you're ignoring the fact that you're not avoiding
the work, you're pushing it out onto other people (who of course must
juggle all the 'specialist rules' for each individual project). I'm
suggesting that's a red herring and that there's a big opportunity cost
(which is why, for example, nobody is forming a credible business case for
the (sonar estimate of 20 man years effort) to 'fix' the 100,000 'major and
above' checkstyle issues in the JDK.
By all means, have some recommendations, a 'house style'. Exportable IDE
settings are a great idea. Review and adjust code where the formatting
makes comprehension and maintenance actively easier (like - naming, logical
grouping, dead code elimination, all that other good, hard stuff that needs
your brain engaged). Concentrate on substantive issues (think about the
maintainer) rather than the trivial -- checkstyle mostly drowns you in
irrelevance.
I'd also far rather commit changes that modify/'correct' styling (and pay
the diff-wall tax) from those that seemingly care deeply than erect yet
another barrier to contributors.
And as someone else pointed out - it's far harder picking over all the
@deprecated obsolescence in core than it is visually parsing the code.
--
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/CAPYP83ShsMGiJwdm1Nz1E8BnrZ6jYJwujWXXOU1h9eEhcpV0pg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
