On Fri, Aug 25, 2017 at 11:03 AM, MG <firstname.lastname@example.org> wrote:
I was just referring to your "You can already leave off the "clutter" and apply a CodeNarc rule to detect "bad" style", which seemed to poke fun at my suggestion - and which I did not quite get: What use would a rule be, if having the clutter that unavoidably comes from having "final" everywhere is exactly what the rule would enforce ?-)
I definitely wasn't trying to poke fun at any suggestions.
Many people consider changing parameters halfway through a long method can be confusing and lead to obscure bugs when the person reading your code wasn't expecting the change. From my agile background days there were two schools of thought on dealing with that issue (mostly in Java land in those days). One is that you should have final everywhere because then the compiler will stop the "bad" style.
The second is that having final everywhere adds lots of "clutter" and makes the code less succinct.
Leave final off but don't change those parameters anyway - and back it up with a checkstyle rule that breaks the build if you ever do.
Advocates of the second style would go on to say that if you have a method that is so long that you might get lost knowing whether a parameter has changed or not, well you have a method that is way too long! :-)
Apart from that I totally get and expect the Devil's advocate approach from your side, I would do the same. If I have a proposal, I'd better expect you to poke it and be prepared to defend it.
Thank you for your suggestions on where to look for info on the local AST transform.
Where can I download "Groovy in Action" ?
Actually, I think an @AutoFinal transform might be a good addition. I'm happy to work on that with you if you like.