Hi. > > > >> > [...] > >> > > >> > The tools are there, but you have to tell people that they _must_ use > >> > them. > >> > >> Commons has already enough rules and process. As long as the releases > >> are have clean code I wouldn't be too anal about the commits in > >> between. > > > > I think that the main disagreement is here. Source code must be a clear read > > for the _developers_. To put it bluntly, I don't care that the releases have > > cleanly formatted code, as almost nobody is going to read those packaged > > sources! > > Nobody objects using Checkstyle. Personally I object a default > Checkstyle config, which everybody must override. Nearly every > components has specifics, so everybody MUST override. What if you > don't want to use Checkstyle? Can you disable it? > What, if you use Sun conventions and Maven conventions are the > default? Much work! Please leave the checkstyle question to where it > belongs, and this is not parent pom, but the individual component. > > And thats what I meant with: as long as we don't have a common > codestyle, i does not make much sense to have a common checkstyle > configuration.
I thought that the question was whether to generate a CheckStyle report, not whether the configuration should be the same... > Secondly, I have not had the feeling in the past years that checkstyle > helped me so much (including non open source projects). And so far, my > code was readable. My code is also readable... I forgot to mention earlier in this thread that a code formatter will not detect missing comments; I've also seen that some people using IDE let the software generate totally useless "place-holder" Javadoc comments. Hence no tool can afterwards detect that documentation is missing. Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
