On Wed, 16 Mar 2022 16:32:09 GMT, Pavel Rappo <pra...@openjdk.org> wrote:
> This PR started in a draft mode as a refactoring effort. After a few commits > and chats with Jonathan Gibbons, I decided that further refactoring belongs > to follow-up PRs and that this PR could be marked as "Ready for review". > > The motivation for the initial refactoring effort was as follows. The word > "tree" is heavily overloaded in the JavaDoc codebase, both in comments and > code. Here are some of the contexts this word appears in: > > * Hierarchy Tree (i.e. overview-tree.html and package-tree.html) > * DocTree (AST nodes) > * ClassTree, *TreeWriter (data structures and entities related to > supertype-subtype relationship) > * HtmlTree (HTML nodes) and specifically UL/OL elements which are nested > lists > > Sometimes contexts overlap, making the word "tree" ambiguous. To reduce this > ambiguity, the word "tree" should be dropped in favor of a more specific word > of phrase where possible. > > In the case where the context is > `jdk.javadoc.internal.doclets.toolkit.Content`, the programmer is already > aware that they are dealing with trees in the sense that `Content` objects > support recursive composition. There's no need to have the phrase "content > tree" where "content" would do. Moreover, in the context that is exclusively > about `Content` objects, the word "content" can be dropped too, since the > type information is assumed. > > As an example of content overlap, have a look at the source of > `jdk.javadoc.internal.doclets.toolkit.builders.MemberSummaryBuilder::buildSummary`. > This method used to needlessly mix DocTree with Content tree. OK ... Well, there's a huge amount of work here, most of which is a genuine improvement, so well done for all that, but I get the sense this work got out of control a bit, given there are many "themes" in this work, each of which would have been a worthy and significant PR in its own right. As a result, the whole is much harder to review than the sum of its parts. The primary theme seems to be to remove the word `tree` from method names and comments when it is either in appropriate or somewhat unnecessary. Amongst the additional themes that are not directly related to the JBS issue: * use of `var` * removing unnecessary comments from overriding methods * use of `{@return}` * minor grammar Don't get me wrong: these are all good improvements. It's just that doing them all together makes it harder to see the trees in the forest. (sic) You are somewhat fortunate in that there is not a lot of major concurrent development in javadoc right now; the merge could have been horrible! So, to summarize, thanks for taking all this on; I'll approve it, but please file JBS issues for any follow-up cleanup that you consider still needs to be done. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java line 268: > 266: * > 267: * @param member the member to get the exception information for > 268: * @return the exception information For later ... use `Returns` Also, maybe better grammar @param member the member for which to get/obtain/ the exception information src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java line 190: > 188: * @param target the content to which the modifiers and type will be > added > 189: */ > 190: protected void addModifierAndType(Element member, TypeMirror type, For later: maybe adjust method name as well src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractOverviewIndexWriter.java line 134: > 132: String doctitle = configuration.getOptions().docTitle(); > 133: if (!doctitle.isEmpty()) { > 134: RawHtml title = new RawHtml(doctitle); why not `var`? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java line 71: > 69: > 70: /** > 71: * The HTML node for constant values summary currently being written. This change seems unnecessary and just in produces an unnecessary synonym src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java line 346: > 344: * > 345: * @param key the key for the desired string > 346: * @return the string No, that suggests it returns the String itself Suggest `content containing the string` src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java line 359: > 357: * @param key the key for the desired string > 358: * @param o0 string or content argument to be formatted into the > result > 359: * @return the string see previous src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java line 373: > 371: * @param o0 string or content argument to be formatted into the > result > 372: * @param o1 string or content argument to be formatted into the > result > 373: * @return the string see previous src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java line 388: > 386: * @param o1 string or content argument to be formatted into the > result > 387: * @param o2 string or content argument to be formatted into the > result > 388: * @return the string see previous src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java line 449: > 447: * > 448: * @param key the key for the desired string > 449: * @return the string see similar src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java line 461: > 459: * > 460: * @param text the string > 461: * @return the string content interesting/inconsistent ;-) src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 321: > 319: * Adds the tags information. > 320: * > 321: * @param e the Element for which the tags will be generated `Element` should be `element` src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1906: > 1904: > 1905: /** > 1906: * {@return the annotation types info for the given element} I would be surprised if this returns content containing the annotation types, as compared to the annotations themselves src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageTreeWriter.java line 93: > 91: > 92: /** > 93: * Generate a separate tree file. Generates src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java line 80: > 78: > 79: /** > 80: * The HTML element for the section tag being written. Hmm, it wasn't wrong to use `tree` here; the goal should not be to remove as many uses of the word `tree` as possible! Future developers will wonder, why does the code avoid all use of the word `tree` src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java line 393: > 391: * Set the return type for an executable member. > 392: * > 393: * @param returnType the return type to add. remove period src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java line 415: > 413: * Set the parameter information of an executable member. > 414: * > 415: * @param content the parameter information. maybe a general cleanup later on fixing trailing periods? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java line 435: > 433: > 434: /** > 435: * Set the annotation information of a member. Sets src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TreeWriter.java line 166: > 164: String title = > resources.getText("doclet.Window_Class_Hierarchy"); > 165: HtmlTree bodyTree = getBody(getWindowTitle(title)); > 166: bodyContents.setHeader(getHeader(PageMode.TREE)); // idempotent why is the comment significant? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Script.java line 102: > 100: > 101: /** > 102: * Returns a "live" view of the script as a {@code Content} object. Don't change it now, but the comment abut a "live view" is sort-of unnecessary because in general most HTMLTree objects are mutable. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ModuleSummaryWriter.java line 64: > 62: > 63: /** > 64: * Wrap the content into summary section. Wraps src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/SerializedFormWriter.java line 71: > 69: > 70: /** > 71: * Add the serialized package to the serialized summaries. Adds ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7843