Re: Checkstyle RedundantThrowsCheck

2009-10-02 Thread Max Berger
Hi Alex, DISCLAIMER: These comments are to be seen as purely academic, and may be complete overkill. For practical purposes, your code is just fine. Alexander Kiel schrieb: In my attachment Tag.java, you can see a variable named value in the constuctor and as field. According the rule, the

Re: Checkstyle RedundantThrowsCheck

2009-10-02 Thread Alexander Kiel
Hi Max, DISCLAIMER: These comments are to be seen as purely academic, and may be complete overkill. For practical purposes, your code is just fine. No, its ok, I like code reviews. - value is a very generic name, and could be reconsidered. What does the value actually specify? Looking at

Re: Checkstyle RedundantThrowsCheck

2009-10-01 Thread Jeremias Maerki
I also find the HiddenField check annoying. So I removed the two rules that were talked about and removed the Checkstyle 3.5 configuration. I haven't deleted the v4 configuration due to Vincent's comment (I've also not upgraded, yet), so I let it stay for the moment. We can always remove it later.

Re: Checkstyle RedundantThrowsCheck

2009-10-01 Thread Max Berger
Hi *, this rule is usefull in the case where you use common names for attributes (such as x, or y), and accidentially overwrite them as parameters. This again comes back to the point of readability. The same variable name should ALWAYS refer to the same variable / value. For setters and

Re: Checkstyle RedundantThrowsCheck

2009-10-01 Thread Jeremias Maerki
Max, I don't think that Checkstyle is the right tool to avoid the self-assignment problem. Tools like FindBugs are much better in that regard since they actually check the semantics of the assignment rather than just complaining that a field and a parameter are named the same. On 01.10.2009

Re: Checkstyle RedundantThrowsCheck

2009-10-01 Thread Alexander Kiel
Hi Max, The same variable name should ALWAYS refer to the same variable / value. I think, I can second this. For setters and constructors this makes sense - after all, in each of these you have a simple assignment, and both variables will carry the same value. In my attachment Tag.java,

Re: Checkstyle RedundantThrowsCheck

2009-10-01 Thread Vincent Hennebert
Hi Max, Thanks for your explanation. Max Berger wrote: Hi *, this rule is usefull in the case where you use common names for attributes (such as x, or y), and accidentially overwrite them as parameters. This again comes back to the point of readability. The same variable name should

Re: Checkstyle RedundantThrowsCheck

2009-09-30 Thread Alexander Kiel
Hi Vincent, Speaking of that, there’s a rule that I would suggest to disable: the HiddenFieldCheck. I don’t really see its benefit. It forces to find somewhat artificial names for variables, where the field name is exactly what I want. Sometimes a method doesn’t have a name following the

Re: Checkstyle RedundantThrowsCheck

2009-09-30 Thread Alexander Kiel
Hi Max, Speaking of that, there’s a rule that I would suggest to disable: the HiddenFieldCheck. I don’t really see its benefit. It forces to find somewhat artificial names for variables, where the field name is exactly what I want. Sometimes a method doesn’t have a name following the

Re: Checkstyle RedundantThrowsCheck

2009-09-29 Thread Vincent Hennebert
Hi Max, Max Berger wrote: Alex, The checkstyle checks are historically grown, and are therefore incomplete. I personally would turn on much more checks for certain style issues I like. IMO every option set helps deciding a certain factor. So more the more checks the better :) If you think

Re: Checkstyle RedundantThrowsCheck

2009-09-29 Thread Max Berger
Vincent, 2009/9/29 Vincent Hennebert vhenneb...@gmail.com: I started to write my own checkstyle configuration from scratch some time ago, enabling everything that looked important to me. But I’d like to test it a bit more before submitting it. Same here. See the checkstyle file for JEuclid

Re: Checkstyle RedundantThrowsCheck

2009-09-29 Thread Vincent Hennebert
Hi Max, Max Berger wrote: Vincent, 2009/9/29 Vincent Hennebert: I started to write my own checkstyle configuration from scratch some time ago, enabling everything that looked important to me. But I’d like to test it a bit more before submitting it. Same here. See the checkstyle file

Re: Checkstyle RedundantThrowsCheck

2009-09-28 Thread Vincent Hennebert
Hi, Jeremias Maerki wrote: On 27.09.2009 13:27:35 Alexander Kiel wrote: Hi Jeremias, Makes sense. I stumbled over that myself from time to time but it didn't really bother me so much to take action. Okay. Can you please modify the checkstyle XML files to reflect that? Sure, but only

Re: Checkstyle RedundantThrowsCheck

2009-09-28 Thread Max Berger
Alex, The checkstyle checks are historically grown, and are therefore incomplete. I personally would turn on much more checks for certain style issues I like. IMO every option set helps deciding a certain factor. So more the more checks the better :) (in short: +1 to your changes). Right now we

Re: Checkstyle RedundantThrowsCheck

2009-09-27 Thread Alexander Kiel
Hi Jeremias, Makes sense. I stumbled over that myself from time to time but it didn't really bother me so much to take action. Okay. Can you please modify the checkstyle XML files to reflect that? I'm a great fan of that checkstyle stuff. I didn't use it before, but I find a common coding

Re: Checkstyle RedundantThrowsCheck

2009-09-27 Thread Jeremias Maerki
On 27.09.2009 13:27:35 Alexander Kiel wrote: Hi Jeremias, Makes sense. I stumbled over that myself from time to time but it didn't really bother me so much to take action. Okay. Can you please modify the checkstyle XML files to reflect that? Sure, but only after a period of at least 72

Re: Checkstyle RedundantThrowsCheck

2009-09-27 Thread Alexander Kiel
Hi Jeremias, Makes sense. I stumbled over that myself from time to time but it didn't really bother me so much to take action. Okay. Can you please modify the checkstyle XML files to reflect that? Sure, but only after a period of at least 72 hours to allow the other committers to

Re: Checkstyle RedundantThrowsCheck

2009-09-26 Thread Jeremias Maerki
Makes sense. I stumbled over that myself from time to time but it didn't really bother me so much to take action. On 26.09.2009 14:41:37 Alexander Kiel wrote: Hi, why didn't our code style allow unchecked exceptions or subclasses of thrown exceptions in Javadoc? From checkstyle-5.0.xml: