Martin Mucha has posted comments on this change. Change subject: core: errors in javadoc, badly placed method. ......................................................................
Patch Set 2: OK, I've fixed problems related to your comments. But lets talk about javadocs conventions some more. a) when I step into class, where A LOT of javadocs are broken. Should I correct them (in separate commit like this one)? Is it observed as beneficial to project / welcomed by other developers? b) is there a convention for javadoc? For example I'm very liberal about them. If they're not faulty, they're good enough for me as long as the method responsibility/purpose is clear; which includes no javadoc. Lets say that I observe documentation of parameter 'taskId' of method 'create', which says "id of task to create", as useless. Is it OK to "not document" such parameters or if javadoc is present all parameters has to be documented somehow? How about present empty parameter documentation? I'm used to dropping that, because it does not offer nothing more that method signature already provides. -- To view, visit http://gerrit.ovirt.org/26065 To unsubscribe, visit http://gerrit.ovirt.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I334d7080989d679fa27082547f1a5950fb530645 Gerrit-PatchSet: 2 Gerrit-Project: ovirt-engine Gerrit-Branch: master Gerrit-Owner: Martin Mucha <[email protected]> Gerrit-Reviewer: Martin Mucha <[email protected]> Gerrit-Reviewer: Moti Asayag <[email protected]> Gerrit-Reviewer: Yair Zaslavsky <[email protected]> Gerrit-Reviewer: Yevgeny Zaspitsky <[email protected]> Gerrit-Reviewer: [email protected] Gerrit-Reviewer: oVirt Jenkins CI Server Gerrit-HasComments: No _______________________________________________ Engine-patches mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-patches
