OK, I've got Checkstyle 2.1 now. I was fooled by the fact that there was no news article for it on the Checkstyle web site, so I thought 2.0.1 was the latest.
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]
