Inline, > > 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 agree, and those because having a rule that do not protect against strange code, seems not a good fit for Checkstyle. > > 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. Yes that is an option.
> > > > > > 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 got idea Checkstyle plugin (CheckStyle-Idea) to work with a slight modification of our configuration, moving "LineLength" module under "Checker" module [1] And got it working nicely with the same result as gradle task. But i'm pretty sure that Eclipse ones will do the job. But this modification break the gradle task... so we need to clear that out. [...] > > > > And like Daniel said, it is a good subject for a community week effort. > > +1 > > To 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 +1 > > - 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. That's the hard part. > > - formatting only where it is necessary (no reformatting of the whole file) +1 Thanks [1] https://github.com/checkstyle/eclipse-cs/issues/190
signature.asc
Description: PGP signature
