Lots of Checkstyle changes to the IdP

[Tom Zeller]

>> it would be nice to get that code Checkstyle clean for 3.3.

Okay I said that. What I meant was “with our existing Checkstyle config” and “clean” = “not perfect” :-) 

> I'll be the first to admit that I do that but it is always in well thought out situations:
> 
> - When Checkstyle has changed the rules under our feet and things which were ok suddenly aren't (the multiple returns case).
>      I'd like to revisit that rule at some stage but it feels that being closer to clean is pre-requisite
> 
> - When essentially linear code breaks method length and/or cyclometric complexity rules.  The two canonical cases are the parsers and (I believe) SWF action beans' execute statements.  I started by trying to avoid this but the code became disgusting; so after discussion we went back to the longer code flows.  In this case Checkstyle clean-ness is opposed to our end.

Thanks for typing up those key points, really, I was hoping you would.

> But there are other much harder (to my mind) cases.  ...  It will take some time to pick them apart and right now my instinct is to live with them 

+1

As an AI, I think adding something to the coding conventions about our Checkstyle suppression “policy” (very loose use of that word there) would be useful. I can add something if I dive back into Checkstyle again, which would be adding the ‘final’ checks etc. to the IdP.

Tom