> Why don't you want a copy of the real javadoc? In my case, I tried to overide toString() and got a huge Javadoc block copied from Object.java. This just clutters the code.
Also, having redundant comments makes the maintenance more difficult because every change is now need to be updated in all the instances. Our style is to mention the super class (which is very easy to jump to using IDEA's browsing capabilities) but to document only the stuff that is specific to the subclass. For example, if we implement MyConnection.toString(), we will have a short javadoc block like: /** * Show as String. For debugging only. We use the port number * to identify the instance. */ Tal > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Jonas Kvarnstr�m > Sent: Tuesday, October 23, 2001 11:14 PM > To: Idea EAP Features > Subject: Re: [Eap-features] Please add Javadoc comment to overidden > method. > > > On Wed, 2001-10-24 at 02:39, Tal Dayan wrote: > > > > When creating a method with the Override Methods command, if the Copy > > Javadoc option > > disabled, I suggest to add to the new method a small javadoc > comment with a > > short summary > > like: > > > > /** > > * Overriding method toString() > > */ > > public String toString() > > { > > return 'xyz'; > > } > > If there is no javadoc comment at all, the javadoc command will copy the > comment from the parent into the HTML output. If IDEA is changed as you > suggest, then this feature wouldn't work as intended... I guess an > ordinary /* */ comment would not be a problem, though. > > (Why don't you want a copy of the real javadoc?) > > > > _______________________________________________ > Eap-features mailing list > [EMAIL PROTECTED] > http://www.intellij.com/mailman/listinfo/eap-features _______________________________________________ Eap-features mailing list [EMAIL PROTECTED] http://www.intellij.com/mailman/listinfo/eap-features
