Hello Tom!
I agree that it is very convenient to be able to see where the method
comes from.
On the other hand what we are discussing is the existence of an
exception to the checkstyle check for 80 char wide lines rules. I will
add that exception back now because I agree that we can allow this.
/Linus
> -----Original Message-----
> From: Tom Morris [mailto:[EMAIL PROTECTED]
[...]
> As far as the @see goes, I think if you review the current code you'll
> find
> a substantial number of occurrences with long lines. I think it's a
waste
> of time to wrap these and having them flagged as errors will obscure
other
> more important errors, discouraging developers from fixing other more
> important style violations.
>
> I actually find it useful to be able to tell at a glance which class
or
> interface a particular method comes from, so I think we should allow
(but
> not require) the non-Javadoc @see comments. Of course, Eclipse
doesn't
> wrap
> them when it inserts them. Talking about short package and class
names
> isn't really relevant now since those were decided on long ago and are
> basically fixed now.
>
> The only disadvantage that I see to /* @see */ is that it has the
> potential
> to get out of date during refactoring. I think this is outweighed by
the
> advantage of having quick reference which is usable on paper or in an
IDE
> without hovering over the name.
>
> What is the disadvantage to allowing them in the default format that
> Eclipse
> uses to insert them (ie unwrapped)?
>
> Tom
>
> -----Original Message-----
> From: Linus Tolke [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 24, 2006 1:24 PM
> To: [email protected]
> Subject: RE: [argouml-dev] The new version of checkclipse
>
>
> Hello Tom!
>
> I have downloaded checklipse 2.1.0 and that has checkstyle 4.2
bundled. I
> guess Michiel has the same because he suggested the logLoadErrors
solution.
> I didn't think more about it since it worked in my Eclipse.
>
> The checklipse 2.1.0 has a problem in that the old .checklipse files
are
> replaced by a .settings/de.mvmsoft.checklipse.prefs file and the
> information
> about files not to be checked is lost in the process. The problem with
> this
> is that I cannot further update the .checklipse file. We will have to
> decide
> when we shall stop supporting the .checklipse file format.
>
> No longer allowing long @see lines is intentional. The reasoning
behind it
> is that I thought that their use was more or less only the required
@see
> comment of overriding and implementing methods. With that requirement
gone,
> the need for allowing this is reduced. Admittedly there is still some
use
> but I think that would be slight. Especially since the use of very
long
> package and class names is not recommended.
>
> I added the flagging of non-Javadoc when I noticed that Eclipse by
default
> had the javadoc comment for new methods set to
> /*
> * (non-Javadoc)
> */
> I very much prefer no comment (in violation with the design
guidelines) to
> this comment (in violation with the design guidelines) added to every
> method. Since I did this we have defined a template for methods and I
> think
> that this or some other Eclipse maturity has reduced the problem.
>
> In what cases would such a non-Javadoc comment be useful? My Eclipse
> colors
> the javadoc comments and the non-javadoc comments differently so for
me
> the
> problem of distinguishing them is so small that I don't feel the need
to
> have non-Javadoc written in every such comment. I guess most
non-Javadoc
> comments use the //-syntax.
>
> /Linus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
