Hi, thank you Denis for having a look at this!
Like Stefan I would also rather adopt the guidelines to existing (good) practice than the other way around. For none of the three points you mention I would agree with the convention :-) Best Regards, Holger > Hi, > > Over time I have noticed several instances where things recommended in > our Coding Conventions [1] are almost nowhere followed, or not followed > at all (anymore). The ones I found are: > > * The conventions say that listeners should always reside in an "events" > subpackage of the package they logically belong to. However, this is > never done anywhere in the core, and also not in the IntelliJ plugin. > As Stefan noted [2], the only place still using that convention is the > UI part of the Eclipse plugin. > > * Empty abstract classes for listeners should be called FooAdapter > according > to the conventions (like in the Java standard library), but seem to be > consistently called AbstractFooListener instead. > > * The conventions recommend several Javadoc tags such as @ui (must be > called from the UI thread), @threadsafe, and others. However, with the > exception of @nonblocking and @blocking, none are really used (several > not at all): > > Tag # Uses > -------------------- > @blocking 28 > @nonblocking 16 > @swt 4 > @caching 2 > @swing 0 > @nonReentrant 0 > @threadsafe 0 > @ui 0 > @valueObject 0 > > > What to do about this? The pragmatic solution would be to just adapt the > conventions > to match the current practice in the code, rather than the other way > around - that > is, dropping mentions of unused tags, removing or altering rules that are > nowhere > followed, etc. What do you think? > > Regards, > Denis > > [1] http://www.saros-project.org/coderules > [2] > http://saros-build.imp.fu-berlin.de/gerrit/#/c/2807/3/de.fu_berlin.inf.dpp.core/src/de/fu_berlin/inf/dpp/editor/events/AbstractSharedEditorListener.java@1 > > ------------------------------------------------------------------------------ > _______________________________________________ > DPP-Devel mailing list > DPP-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dpp-devel > ------------------------------------------------------------------------------ _______________________________________________ DPP-Devel mailing list DPP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dpp-devel
