Hi Gil, thanks for your thoughts. Inline...
Am 13.02.20 um 21:12 schrieb Gil Portenseigne:
Hello Michael, Adapting checkstyle configuration is less impacting to our codebase but make us stay different from the java standard. That is the easier path, that will not affect code history. But about getting nearer from the java standard is IMO a nice to have, to make pure java developer feel better discovering OFBiz. I'm kinda prefer the "opposite approach", but we need to discuss if this improvement is worth the history lost. In the example you chose, i see no issue capitalizing module, resource and other. Updating the rule offer the ability to write a constant like : MoDuLe :-).
So you are suggesting to use the default configuration for constant names and do a refactoring to make the private constants like module, ressource, ressource_error follow this configuration (capitalized with underscores)? This would result lots of modifications.
I've also seen a configuration option apply the pattern only to public/protected constants which could be an alternative to reduce the amount of changes, at least in the first iterations.
I am open for these alternatives, as long as we can manage to get it into the codebase smoothly.
Lots of errors are about line that are 120+ length, missing or uneeded space etc. So that will lead to loads of unrisky modifications. With the usage of IDE with checkstyle plugin this can be done nicely.
I've seen several plugins for Eclipse, any suggestions of a plugin which is able to use our configuration?
I check that over the near thousand of java file concerned more than 80% have less than 50 issue... So we can focus our effort onto the big files using a branch to test the idea and ease the issue. And like Daniel said, it is a good subject for a community week effort.
+1To make this work out and keep it manageable, we should define some "rules" how to approach this.
For example, I'm thinking of- a clear separation of checkstyle modifications and other code corrections which might come to mind when reading the code
- checkstyle modifications should not change the functionality/program code in any way. Which means that open API should not be changed either (e.g. public constants that might be used in third party functionality). If we want to change them, we should deprecate the old and remove in the upcoming release branch. So this needs some caution.
- formatting only where it is necessary (no reformatting of the whole file) - ... This would make it easier for committers to review and accept the changes.If IDE plugins are used, they should be able to read the config/checkstyle.xml to use the same configuration for every check.
I'd really like to be able to efficiently use this feature, in one way or the other, so thank you for starting this discussion. Regards, Gil
Thanks Gil, Michael Brohl ecomify GmbH - www.ecomify.de
smime.p7s
Description: S/MIME Cryptographic Signature
