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
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
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.
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
Hi,
why didn't our code style allow unchecked exceptions or subclasses of
thrown exceptions in Javadoc?
From checkstyle-5.0.xml:
module name=RedundantThrowsCheck
property name=allowSubclasses value=false/
property name=allowUnchecked value=false/
property name=severity
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:
19 matches
Mail list logo
