├── .gitignore
├── LICENSE
├── README.md
└── docs
├── .nojekyll
├── README.md
├── _coverpage.md
├── _navbar.md
├── _sidebar.md
├── assets
└── images
│ ├── add-blinkfox-checks-success.png
│ ├── add-blinkfox-checks.png
│ ├── idea-check.png
│ ├── idea-checkstyle-plugin.png
│ ├── import-idea-style-xml.png
│ └── logo.png
├── checks
├── blinkfox-checks.xml
├── blinkfox-idea-java-style.xml
└── google-checks.xml
├── favicon.ico
├── guide
├── blinkfox-java-style-guide.md
├── google-java-style-guide-cn.md
└── google-java-style-guide.md
├── index.html
└── styles
├── blinkfox-checks.md
├── blinkfox-idea-java-style.md
└── google-checks.md
/.gitignore:
--------------------------------------------------------------------------------
1 | ### IntelliJ IDEA ###
2 | .idea
3 | *.iws
4 | *.iml
5 | *.ipr
6 |
7 | ### VS Code ###
8 | .vscode/
9 |
--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
1 | Apache License
2 | Version 2.0, January 2004
3 | http://www.apache.org/licenses/
4 |
5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
6 |
7 | 1. Definitions.
8 |
9 | "License" shall mean the terms and conditions for use, reproduction,
10 | and distribution as defined by Sections 1 through 9 of this document.
11 |
12 | "Licensor" shall mean the copyright owner or entity authorized by
13 | the copyright owner that is granting the License.
14 |
15 | "Legal Entity" shall mean the union of the acting entity and all
16 | other entities that control, are controlled by, or are under common
17 | control with that entity. For the purposes of this definition,
18 | "control" means (i) the power, direct or indirect, to cause the
19 | direction or management of such entity, whether by contract or
20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the
21 | outstanding shares, or (iii) beneficial ownership of such entity.
22 |
23 | "You" (or "Your") shall mean an individual or Legal Entity
24 | exercising permissions granted by this License.
25 |
26 | "Source" form shall mean the preferred form for making modifications,
27 | including but not limited to software source code, documentation
28 | source, and configuration files.
29 |
30 | "Object" form shall mean any form resulting from mechanical
31 | transformation or translation of a Source form, including but
32 | not limited to compiled object code, generated documentation,
33 | and conversions to other media types.
34 |
35 | "Work" shall mean the work of authorship, whether in Source or
36 | Object form, made available under the License, as indicated by a
37 | copyright notice that is included in or attached to the work
38 | (an example is provided in the Appendix below).
39 |
40 | "Derivative Works" shall mean any work, whether in Source or Object
41 | form, that is based on (or derived from) the Work and for which the
42 | editorial revisions, annotations, elaborations, or other modifications
43 | represent, as a whole, an original work of authorship. For the purposes
44 | of this License, Derivative Works shall not include works that remain
45 | separable from, or merely link (or bind by name) to the interfaces of,
46 | the Work and Derivative Works thereof.
47 |
48 | "Contribution" shall mean any work of authorship, including
49 | the original version of the Work and any modifications or additions
50 | to that Work or Derivative Works thereof, that is intentionally
51 | submitted to Licensor for inclusion in the Work by the copyright owner
52 | or by an individual or Legal Entity authorized to submit on behalf of
53 | the copyright owner. For the purposes of this definition, "submitted"
54 | means any form of electronic, verbal, or written communication sent
55 | to the Licensor or its representatives, including but not limited to
56 | communication on electronic mailing lists, source code control systems,
57 | and issue tracking systems that are managed by, or on behalf of, the
58 | Licensor for the purpose of discussing and improving the Work, but
59 | excluding communication that is conspicuously marked or otherwise
60 | designated in writing by the copyright owner as "Not a Contribution."
61 |
62 | "Contributor" shall mean Licensor and any individual or Legal Entity
63 | on behalf of whom a Contribution has been received by Licensor and
64 | subsequently incorporated within the Work.
65 |
66 | 2. Grant of Copyright License. Subject to the terms and conditions of
67 | this License, each Contributor hereby grants to You a perpetual,
68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable
69 | copyright license to reproduce, prepare Derivative Works of,
70 | publicly display, publicly perform, sublicense, and distribute the
71 | Work and such Derivative Works in Source or Object form.
72 |
73 | 3. Grant of Patent License. Subject to the terms and conditions of
74 | this License, each Contributor hereby grants to You a perpetual,
75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable
76 | (except as stated in this section) patent license to make, have made,
77 | use, offer to sell, sell, import, and otherwise transfer the Work,
78 | where such license applies only to those patent claims licensable
79 | by such Contributor that are necessarily infringed by their
80 | Contribution(s) alone or by combination of their Contribution(s)
81 | with the Work to which such Contribution(s) was submitted. If You
82 | institute patent litigation against any entity (including a
83 | cross-claim or counterclaim in a lawsuit) alleging that the Work
84 | or a Contribution incorporated within the Work constitutes direct
85 | or contributory patent infringement, then any patent licenses
86 | granted to You under this License for that Work shall terminate
87 | as of the date such litigation is filed.
88 |
89 | 4. Redistribution. You may reproduce and distribute copies of the
90 | Work or Derivative Works thereof in any medium, with or without
91 | modifications, and in Source or Object form, provided that You
92 | meet the following conditions:
93 |
94 | (a) You must give any other recipients of the Work or
95 | Derivative Works a copy of this License; and
96 |
97 | (b) You must cause any modified files to carry prominent notices
98 | stating that You changed the files; and
99 |
100 | (c) You must retain, in the Source form of any Derivative Works
101 | that You distribute, all copyright, patent, trademark, and
102 | attribution notices from the Source form of the Work,
103 | excluding those notices that do not pertain to any part of
104 | the Derivative Works; and
105 |
106 | (d) If the Work includes a "NOTICE" text file as part of its
107 | distribution, then any Derivative Works that You distribute must
108 | include a readable copy of the attribution notices contained
109 | within such NOTICE file, excluding those notices that do not
110 | pertain to any part of the Derivative Works, in at least one
111 | of the following places: within a NOTICE text file distributed
112 | as part of the Derivative Works; within the Source form or
113 | documentation, if provided along with the Derivative Works; or,
114 | within a display generated by the Derivative Works, if and
115 | wherever such third-party notices normally appear. The contents
116 | of the NOTICE file are for informational purposes only and
117 | do not modify the License. You may add Your own attribution
118 | notices within Derivative Works that You distribute, alongside
119 | or as an addendum to the NOTICE text from the Work, provided
120 | that such additional attribution notices cannot be construed
121 | as modifying the License.
122 |
123 | You may add Your own copyright statement to Your modifications and
124 | may provide additional or different license terms and conditions
125 | for use, reproduction, or distribution of Your modifications, or
126 | for any such Derivative Works as a whole, provided Your use,
127 | reproduction, and distribution of the Work otherwise complies with
128 | the conditions stated in this License.
129 |
130 | 5. Submission of Contributions. Unless You explicitly state otherwise,
131 | any Contribution intentionally submitted for inclusion in the Work
132 | by You to the Licensor shall be under the terms and conditions of
133 | this License, without any additional terms or conditions.
134 | Notwithstanding the above, nothing herein shall supersede or modify
135 | the terms of any separate license agreement you may have executed
136 | with Licensor regarding such Contributions.
137 |
138 | 6. Trademarks. This License does not grant permission to use the trade
139 | names, trademarks, service marks, or product names of the Licensor,
140 | except as required for reasonable and customary use in describing the
141 | origin of the Work and reproducing the content of the NOTICE file.
142 |
143 | 7. Disclaimer of Warranty. Unless required by applicable law or
144 | agreed to in writing, Licensor provides the Work (and each
145 | Contributor provides its Contributions) on an "AS IS" BASIS,
146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
147 | implied, including, without limitation, any warranties or conditions
148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
149 | PARTICULAR PURPOSE. You are solely responsible for determining the
150 | appropriateness of using or redistributing the Work and assume any
151 | risks associated with Your exercise of permissions under this License.
152 |
153 | 8. Limitation of Liability. In no event and under no legal theory,
154 | whether in tort (including negligence), contract, or otherwise,
155 | unless required by applicable law (such as deliberate and grossly
156 | negligent acts) or agreed to in writing, shall any Contributor be
157 | liable to You for damages, including any direct, indirect, special,
158 | incidental, or consequential damages of any character arising as a
159 | result of this License or out of the use or inability to use the
160 | Work (including but not limited to damages for loss of goodwill,
161 | work stoppage, computer failure or malfunction, or any and all
162 | other commercial damages or losses), even if such Contributor
163 | has been advised of the possibility of such damages.
164 |
165 | 9. Accepting Warranty or Additional Liability. While redistributing
166 | the Work or Derivative Works thereof, You may choose to offer,
167 | and charge a fee for, acceptance of support, warranty, indemnity,
168 | or other liability obligations and/or rights consistent with this
169 | License. However, in accepting such obligations, You may act only
170 | on Your own behalf and on Your sole responsibility, not on behalf
171 | of any other Contributor, and only if You agree to indemnify,
172 | defend, and hold each Contributor harmless for any liability
173 | incurred by, or claims asserted against, such Contributor by reason
174 | of your accepting any such warranty or additional liability.
175 |
176 | END OF TERMS AND CONDITIONS
177 |
178 | APPENDIX: How to apply the Apache License to your work.
179 |
180 | To apply the Apache License to your work, attach the following
181 | boilerplate notice, with the fields enclosed by brackets "[]"
182 | replaced with your own identifying information. (Don't include
183 | the brackets!) The text should be enclosed in the appropriate
184 | comment syntax for the file format. We also recommend that a
185 | file or class name and description of purpose be included on the
186 | same "printed page" as the copyright notice for easier
187 | identification within third-party archives.
188 |
189 | Copyright [yyyy] [name of copyright owner]
190 |
191 | Licensed under the Apache License, Version 2.0 (the "License");
192 | you may not use this file except in compliance with the License.
193 | You may obtain a copy of the License at
194 |
195 | http://www.apache.org/licenses/LICENSE-2.0
196 |
197 | Unless required by applicable law or agreed to in writing, software
198 | distributed under the License is distributed on an "AS IS" BASIS,
199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
200 | See the License for the specific language governing permissions and
201 | limitations under the License.
202 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 |
490 | * Strings are constant; their values cannot be changed after they
491 | * are created. String buffers support mutable strings.
492 | * Because String objects are immutable they can be shared. For example:
493 | *
510 | * The class {@code String} includes methods for examining
511 | * individual characters of the sequence, for comparing strings, for
512 | * searching strings, for extracting substrings, and for creating a
513 | * copy of a string with all characters translated to uppercase or to
514 | * lowercase. Case mapping is based on the Unicode Standard version
515 | * specified by the {@link java.lang.Character Character} class.
516 | *
517 | * The Java language provides special support for the string
518 | * concatenation operator ( + ), and for conversion of
519 | * other objects to strings. String concatenation is implemented
520 | * through the {@code StringBuilder}(or {@code StringBuffer})
521 | * class and its {@code append} method.
522 | * String conversions are implemented through the method
523 | * {@code toString}, defined by {@code Object} and
524 | * inherited by all classes in Java. For additional information on
525 | * string concatenation and conversion, see Gosling, Joy, and Steele,
526 | * The Java Language Specification.
527 | *
528 | *
Unless otherwise noted, passing a null argument to a constructor
529 | * or method in this class will cause a {@link NullPointerException} to be
530 | * thrown.
531 | *
532 | *
A {@code String} represents a string in the UTF-16 format
533 | * in which supplementary characters are represented by surrogate
534 | * pairs (see the section Unicode
535 | * Character Representations in the {@code Character} class for
536 | * more information).
537 | * Index values refer to {@code char} code units, so a supplementary
538 | * character uses two positions in a {@code String}.
539 | *
`，并且它和第一个单词间没有空格。
671 |
672 | #### 7.1.3 Javadoc 标记
673 |
674 | 标准的 Javadoc 注解标记按以下顺序出现：`@param`, `@return`, `@throws`, `@deprecated`, 前面这 4 种标记如果出现，描述都不能为空。当描述无法在一行中容纳，连续行需要至少在 `@` 符号的位置处缩进 `4` 个空格。
675 |
676 | #### 7.2 摘要片段
677 |
678 | 每个 Javadoc 都以一个简短的**摘要片段**开始。这个片段是非常重要的，它是文本在某些上下文（如类和方法索引）中出现的唯一部分。
679 |
680 | 这只是一个小片段，可以是一个名词短语或动词短语，但不是一个完整的句子。它不会以 `A {@code Foo} is a...` 或者 `This method returns...` 开头, 它也不会是一个完整的祈使句，如 `Save the record.`。但是，由于开头大写且被加了标点符号，它看起来就像是个完整的句子。
681 |
682 | > **提示**：一个常见的错误是把简单的 Javadoc 写成 `/** @return the customer ID */`，这是不正确的。它应该写成 `/** Returns the customer ID. */`。
683 |
684 | ### 7.3 在哪里使用 Javadoc
685 |
686 | 至少在每个 `public` 类及它的每个 `public` 和 `protected` 成员处使用 Javadoc，下面会提到一些例外情况：
687 |
688 | 额外的 Javadoc 内容也可能存在，如第 7.3.4 节[非必需的Javadoc](#)。
689 |
690 | #### 7.3.1 例外：不言自明的方法
691 |
692 | 对于简单明显的方法如 `getFoo`，Javadoc 是可选的。这种情况下除了写 “`Returns the foo`”，确实也没有什么值得写了。
693 |
694 | > **重要提示**：如果有一些相关信息是需要读者了解的，那么以上的例外不应作为忽视这些信息的理由。例如，对于 `getCanonicalName` 方法，就不应该忽视文档说明，因为读者很可能不知道词语 “`canonical name`” 指的是什么。
695 |
696 | #### 7.3.2 例外：重写
697 |
698 | 如果一个方法重写了超类中的方法，那么 Javadoc 并非必需的。
699 |
700 | #### 7.3.3 可选的 Javadoc
701 |
702 | 对于包外不可见的类和方法，如有需要，也是要使用 Javadoc 的。如果一个注释是用来定义一个类，方法，字段的整体目的或行为，那么这个注释应该写成 Javadoc，这样更统一、更友好。
703 |
704 | #### 7.3.4 不需要 Javadoc 的情况
705 |
706 | 其他类和成员种根据实际是否需要来写 Javadoc。
707 |
708 | 每当将注释用于定义类或成员的总体目的或行为时，该注释就会改为使用 Javadoc 来编写（使用`/**`）。
709 |
710 | 非必需的 Javadoc 并不要求严格遵循第 7.1.2、7.1.3 和 7.2 节的格式化规则，当然是推荐遵循的。
711 |
--------------------------------------------------------------------------------
/docs/guide/google-java-style-guide.md:
--------------------------------------------------------------------------------
1 | # Google Java Style Guide
2 |
3 | ## 1 Introduction
4 |
5 | This document serves as the **complete** definition of Google's coding standards for source code in the Java™ Programming Language. A Java source file is described as being in Google Style if and only if it adheres to the rules herein.
6 |
7 | Like other programming style guides, the issues covered span not only aesthetic issues of formatting, but other types of conventions or coding standards as well. However, this document focuses primarily on the **hard-and-fast** rules that we follow universally, and avoids giving advice that isn't clearly enforceable (whether by human or tool).
8 |
9 | ### 1.1 Terminology notes
10 |
11 | In this document, unless otherwise clarified:
12 |
13 | 1. The term `class` is used inclusively to mean an "ordinary" class, enum class, interface or annotation type (`@interface`).
14 | 2. The term `member` (of a class) is used inclusively to mean a nested class, field, method, or constructor; that is, all top-level contents of a class except initializers and comments.
15 | 3. The term `comment` always refers to implementation comments. We do not use the phrase "documentation comments", instead using the common term "Javadoc."
16 |
17 | Other "terminology notes" will appear occasionally throughout the document.
18 |
19 | ### 1.2 Guide notes
20 |
21 | Example code in this document is **non-normative**. That is, while the examples are in Google Style, they may not illustrate the only stylish way to represent the code. Optional formatting choices made in examples should not be enforced as rules.
22 |
23 | ## 2 Source file basics
24 |
25 | ### 2.1 File name
26 |
27 | The source file name consists of the case-sensitive name of the top-level class it contains (of which there is [exactly one](https://checkstyle.sourceforge.io/styleguides/google-java-style-20180523/javaguide.html#s3.4.1-one-top-level-class)), plus the `.java` extension.
28 |
29 | ### 2.2 File encoding: UTF-8
30 |
31 | Source files are encoded in **UTF-8**.
32 |
33 | ### 2.3 Special characters
34 |
35 | #### 2.3.1 Whitespace characters
36 |
37 | Aside from the line terminator sequence, the **ASCII horizontal space character (`0x20`)** is the only whitespace character that appears anywhere in a source file. This implies that:
38 |
39 | 1. All other whitespace characters in string and character literals are escaped.
40 | 2. Tab characters are **not** used for indentation.
41 |
42 | #### 2.3.2 Special escape sequences
43 |
44 | For any character that has a [special escape sequence](http://docs.oracle.com/javase/tutorial/java/data/characters.html) (`\b`, `\t`, `\n`, `\f`, `\r`, `\"`, `\'` and `\\`), that sequence is used rather than the corresponding octal (e.g. `\012`) or Unicode (e.g. `\u000a`) escape.
45 |
46 | #### 2.3.3 Non-ASCII characters
47 |
48 | For the remaining non-ASCII characters, either the actual Unicode character (e.g. `∞`) or the equivalent Unicode escape (e.g. `\u221e`) is used. The choice depends only on which makes the code **easier to read and understand**, although Unicode escapes outside string literals and comments are strongly discouraged.
49 |
50 | > **Tip**: In the Unicode escape case, and occasionally even when actual Unicode characters are used, an explanatory comment can be very helpful.
51 |
52 | Examples:
53 |
54 | | Example | Discussion |
55 | | ------------------------------------------------------ | ------------------------------------------------------------ |
56 | | String unitAbbrev = "μs"; | Best: perfectly clear even without a comment. |
57 | | String unitAbbrev = "\u03bcs"; // "μs" | Allowed, but there's no reason to do this. |
58 | | String unitAbbrev = "\u03bcs"; // Greek letter mu, "s" | Allowed, but awkward and prone to mistakes. |
59 | | String unitAbbrev = "\u03bcs"; | Poor: the reader has no idea what this is. |
60 | | return '\ufeff' + content; // byte order mark | Good: use escapes for non-printable characters, and comment if necessary. |
61 |
62 | > **Tip**: Never make your code less readable simply out of fear that some programs might not handle non-ASCII characters properly. If that should happen, those programs are **broken** and they must be **fixed**.
63 |
64 | ## 3 Source file structure
65 |
66 | A source file consists of, **in order**:
67 |
68 | 1. License or copyright information, if present
69 | 2. Package statement
70 | 3. Import statements
71 | 4. Exactly one top-level class
72 |
73 | **Exactly one blank line** separates each section that is present.
74 |
75 | ### 3.1 License or copyright information, if present
76 |
77 | If license or copyright information belongs in a file, it belongs here.
78 |
79 | ### 3.2 Package statement
80 |
81 | The package statement is **not line-wrapped**. The column limit (Section 4.4, [Column limit: 100](#)) does not apply to package statements.
82 |
83 | ### 3.3 Import statements
84 |
85 | #### 3.3.1 No wildcard imports
86 |
87 | **Wildcard imports**, static or otherwise, **are not used**.
88 |
89 | #### 3.3.2 No line-wrapping
90 |
91 | Import statements are **not line-wrapped**. The column limit (Section 4.4, [Column limit: 100](#)) does not apply to import statements.
92 |
93 | #### 3.3.3 Ordering and spacing
94 |
95 | Imports are ordered as follows:
96 |
97 | 1. All static imports in a single block.
98 | 2. All non-static imports in a single block.
99 |
100 | If there are both static and non-static imports, a single blank line separates the two blocks. There are no other blank lines between import statements.
101 |
102 | Within each block the imported names appear in ASCII sort order. (**Note**: this is not the same as the import statements being in ASCII sort order, since '.' sorts before ';'.)
103 |
104 | #### 3.3.4 No static import for classes
105 |
106 | Static import is not used for static nested classes. They are imported with normal imports.
107 |
108 | ### 3.4 Class declaration
109 |
110 | #### 3.4.1 Exactly one top-level class declaration
111 |
112 | Each top-level class resides in a source file of its own.
113 |
114 | #### 3.4.2 Ordering of class contents
115 |
116 | The order you choose for the members and initializers of your class can have a great effect on learnability. However, there's no single correct recipe for how to do it; different classes may order their contents in different ways.
117 |
118 | What is important is that each class uses **some logical order**, which its maintainer could explain if asked. For example, new methods are not just habitually added to the end of the class, as that would yield "chronological by date added" ordering, which is not a logical ordering.
119 |
120 | ##### 3.4.2.1 Overloads: never split
121 |
122 | When a class has multiple constructors, or multiple methods with the same name, these appear sequentially, with no other code in between (not even private members).
123 |
124 | ## 4 Formatting
125 |
126 | **Terminology Note**: block-like construct refers to the body of a class, method or constructor. Note that, by Section 4.8.3.1 on array initializers, any array initializer may optionally be treated as if it were a block-like construct.
127 |
128 | ### 4.1 Braces
129 |
130 | #### 4.1.1 Braces are used where optional
131 |
132 | Braces are used with if, else, for, do and while statements, even when the body is empty or contains only a single statement.
133 |
134 | #### 4.1.2 Nonempty blocks: K & R style
135 |
136 | Braces follow the Kernighan and Ritchie style (["Egyptian brackets"](http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html)) for nonempty blocks and block-like constructs:
137 |
138 | - No line break before the opening brace.
139 | - Line break after the opening brace.
140 | - Line break before the closing brace.
141 | - Line break after the closing brace, only if that brace terminates a statement or terminates the body of a method, constructor, or named class. For example, there is no line break after the brace if it is followed by `else` or a comma.
142 |
143 | Examples:
144 |
145 | ```java
146 | return () -> {
147 | while (condition()) {
148 | method();
149 | }
150 | };
151 |
152 | return new MyClass() {
153 | @Override public void method() {
154 | if (condition()) {
155 | try {
156 | something();
157 | } catch (ProblemException e) {
158 | recover();
159 | }
160 | } else if (otherCondition()) {
161 | somethingElse();
162 | } else {
163 | lastThing();
164 | }
165 | }
166 | };
167 | ```
168 |
169 | A few exceptions for enum classes are given in Section 4.8.1, [Enum classes](https://checkstyle.sourceforge.io/styleguides/google-java-style-20180523/javaguide.html#s4.8.1-enum-classes).
170 |
171 | #### 4.1.3 Empty blocks: may be concise
172 |
173 | An empty block or block-like construct may be in K & R style (as described in Section 4.1.2). Alternatively, it may be closed immediately after it is opened, with no characters or line break in between ({}), unless it is part of a multi-block statement (one that directly contains multiple blocks: if/else or try/catch/finally).
174 |
175 | Examples:
176 |
177 | ```java
178 | // This is acceptable
179 | void doNothing() {}
180 |
181 | // This is equally acceptable
182 | void doNothingElse() {
183 | }
184 | ```
185 |
186 | ```java
187 | // This is not acceptable: No concise empty blocks in a multi-block statement
188 | try {
189 | doSomething();
190 | } catch (Exception e) {}
191 | ```
192 |
193 | ### 4.2 Block indentation: +2 spaces
194 |
195 | Each time a new block or block-like construct is opened, the indent increases by two spaces. When the block ends, the indent returns to the previous indent level. The indent level applies to both code and comments throughout the block. (See the example in Section 4.1.2, [Nonempty blocks: K & R Style](#).)
196 |
197 | ### 4.3 One statement per line
198 |
199 | Each statement is followed by a line break.
200 |
201 | ### 4.4 Column limit: 100
202 |
203 | Java code has a column limit of 100 characters. A "character" means any Unicode code point. Except as noted below, any line that would exceed this limit must be line-wrapped, as explained in Section 4.5, [Line-wrapping](#).
204 |
205 | > Each Unicode code point counts as one character, even if its display width is greater or less. For example, if using [fullwidth characters](https://en.wikipedia.org/wiki/Halfwidth_and_fullwidth_forms), you may choose to wrap the line earlier than where this rule strictly requires.
206 |
207 | Exceptions:
208 |
209 | 1. Lines where obeying the column limit is not possible (for example, a long URL in Javadoc, or a long JSNI method reference).
210 | 2. `package` and `import` statements (see Sections 3.2 [Package statement](#) and 3.3 [Import statements](#)).
211 | 3. Command lines in a comment that may be cut-and-pasted into a shell.
212 |
213 | ### 4.5 Line-wrapping
214 |
215 | **Terminology Note**: When code that might otherwise legally occupy a single line is divided into multiple lines, this activity is called line-wrapping.
216 |
217 | There is no comprehensive, deterministic formula showing exactly how to line-wrap in every situation. Very often there are several valid ways to line-wrap the same piece of code.
218 |
219 | > **Note**: While the typical reason for line-wrapping is to avoid overflowing the column limit, even code that would in fact fit within the column limit may be line-wrapped at the author's discretion.
220 |
221 | > **Tip**: Extracting a method or local variable may solve the problem without the need to line-wrap.
222 |
223 | #### 4.5.1 Where to break
224 |
225 | The prime directive of line-wrapping is: prefer to break at a **higher syntactic level**. Also:
226 |
227 | 1. When a line is broken at a non-assignment operator the break comes before the symbol. (Note that this is not the same practice used in Google style for other languages, such as C++ and JavaScript.)
228 | - This also applies to the following "operator-like" symbols:
229 | - the dot separator (`.`)
230 | - the two colons of a method reference (`::`)
231 | - an ampersand in a type bound (``)
232 | - a pipe in a catch block (`catch (FooException | BarException e)`).
233 | 2. When a line is broken at an assignment operator the break typically comes after the symbol, but either way is acceptable.
234 | - This also applies to the "assignment-operator-like" colon in an enhanced `for` ("`foreach`") statement.
235 | 3. A method or constructor name stays attached to the open parenthesis (`(`) that follows it.
236 | 4. A comma (`,`) stays attached to the token that precedes it.
237 | 5. A line is never broken adjacent to the arrow in a lambda, except that a break may come immediately after the arrow if the body of the lambda consists of a single unbraced expression. Examples:
238 |
239 | ```java
240 | MyLambda lambda =
241 | (String label, Long value, Object obj) -> {
242 | ...
243 | };
244 |
245 | Predicate predicate = str ->
246 | longExpressionInvolving(str);
247 | ```
248 |
249 | > **Note**: The primary goal for line wrapping is to have clear code, not necessarily code that fits in the smallest number of lines.
250 |
251 | #### 4.5.2 Indent continuation lines at least +4 spaces
252 |
253 | When line-wrapping, each line after the first (each continuation line) is indented at least +4 from the original line.
254 |
255 | When there are multiple continuation lines, indentation may be varied beyond +4 as desired. In general, two continuation lines use the same indentation level if and only if they begin with syntactically parallel elements.
256 |
257 | Section 4.6.3 on [Horizontal alignment](#) addresses the discouraged practice of using a variable number of spaces to align certain tokens with previous lines.
258 |
259 | ### 4.6 Whitespace
260 |
261 | #### 4.6.1 Vertical Whitespace
262 |
263 | A single blank line always appears:
264 |
265 | 1. Between consecutive members or initializers of a class: fields, constructors, methods, nested classes, static initializers, and instance initializers.
266 | - **Exception**: A blank line between two consecutive fields (having no other code between them) is optional. Such blank lines are used as needed to create logical groupings of fields.
267 | - **Exception**: Blank lines between enum constants are covered in [Section 4.8.1](#).
268 | 1. As required by other sections of this document (such as Section 3, [Source file structure](#), and Section 3.3, [Import statements](#)).
269 |
270 | A single blank line may also appear anywhere it improves readability, for example between statements to organize the code into logical subsections. A blank line before the first member or initializer, or after the last member or initializer of the class, is neither encouraged nor discouraged.
271 |
272 | Multiple consecutive blank lines are permitted, but never required (or encouraged).
273 |
274 | #### 4.6.2 Horizontal whitespace
275 |
276 | Beyond where required by the language or other style rules, and apart from literals, comments and Javadoc, a single ASCII space also appears in the following places only.
277 |
278 | 1. Separating any reserved word, such as `if`, `for` or `catch`, from an open parenthesis (`(`) that follows it on that line
279 | 2. Separating any reserved word, such as `else` or `catch`, from a closing curly brace (`}`) that precedes it on that line
280 | 3. Before any open curly brace (`{`), with two exceptions:
281 | - `@SomeAnnotation({a, b})` (no space is used)
282 | - `String[][] x = {{"foo"}};` (no space is required between {{, by item 8 below)
283 | 4. On both sides of any binary or ternary operator. This also applies to the following "operator-like" symbols:
284 | - the ampersand in a conjunctive type bound: ``
285 | - the pipe for a catch block that handles multiple exceptions: `catch (FooException | BarException e)`
286 | - the colon (`:`) in an enhanced `for` ("`foreach`") statement
287 | - the arrow in a lambda expression: `(String str) -> str.length()`
288 | but not
289 | - the two colons (`::`) of a method reference, which is written like `Object::toString`
290 | - the dot separator (`.`), which is written like `object.toString()`
291 | 1. After `,:;` or the closing parenthesis (`)`) of a cast
292 | 2. On both sides of the double slash (`//`) that begins an end-of-line comment. Here, multiple spaces are allowed, but not required.
293 | 3. Between the type and variable of a declaration: `List list`
294 | 4. Optional just inside both braces of an array initializer
295 | - `new int[] {5, 6}` and `new int[] { 5, 6 }` are both valid
296 | 9. Between a type annotation and `[]` or `...`.
297 |
298 | This rule is never interpreted as requiring or forbidding additional space at the start or end of a line; it addresses only interior space.
299 |
300 | #### 4.6.3 Horizontal alignment: never required
301 |
302 | **Terminology Note**: Horizontal alignment is the practice of adding a variable number of additional spaces in your code with the goal of making certain tokens appear directly below certain other tokens on previous lines.
303 |
304 | This practice is permitted, but is **never required** by Google Style. It is not even required to maintain horizontal alignment in places where it was already used.
305 |
306 | Here is an example without alignment, then using alignment:
307 |
308 | ```java
309 | private int x; // this is fine
310 | private Color color; // this too
311 |
312 | private int x; // permitted, but future edits
313 | private Color color; // may leave it unaligned
314 | ```
315 |
316 | > **Tip**: Alignment can aid readability, but it creates problems for future maintenance. Consider a future change that needs to touch just one line. This change may leave the formerly-pleasing formatting mangled, and that is **allowed**. More often it prompts the coder (perhaps you) to adjust whitespace on nearby lines as well, possibly triggering a cascading series of reformattings. That one-line change now has a "blast radius." This can at worst result in pointless busywork, but at best it still corrupts version history information, slows down reviewers and exacerbates merge conflicts.
317 |
318 | ### 4.7 Grouping parentheses: recommended
319 |
320 | Optional grouping parentheses are omitted only when author and reviewer agree that there is no reasonable chance the code will be misinterpreted without them, nor would they have made the code easier to read. It is not reasonable to assume that every reader has the entire Java operator precedence table memorized.
321 |
322 | ### 4.8 Specific constructs
323 |
324 | #### 4.8.1 Enum classes
325 |
326 | After each comma that follows an enum constant, a line break is optional. Additional blank lines (usually just one) are also allowed. This is one possibility:
327 |
328 | ```java
329 | private enum Answer {
330 | YES {
331 | @Override public String toString() {
332 | return "yes";
333 | }
334 | },
335 |
336 | NO,
337 | MAYBE
338 | }
339 | ```
340 |
341 | An enum class with no methods and no documentation on its constants may optionally be formatted as if it were an array initializer (see Section 4.8.3.1 on [array initializers](#)).
342 |
343 | ```java
344 | private enum Suit { CLUBS, HEARTS, SPADES, DIAMONDS }
345 | ```
346 |
347 | Since enum classes are classes, all other rules for formatting classes apply.
348 |
349 | #### 4.8.2 Variable declarations
350 |
351 | ##### 4.8.2.1 One variable per declaration
352 |
353 | Every variable declaration (field or local) declares only one variable: declarations such as `int a, b;` are not used.
354 |
355 | **Exception**: Multiple variable declarations are acceptable in the header of a `for` loop.
356 |
357 | ##### 4.8.2.2 Declared when needed
358 |
359 | Local variables are not habitually declared at the start of their containing block or block-like construct. Instead, local variables are declared close to the point they are first used (within reason), to minimize their scope. Local variable declarations typically have initializers, or are initialized immediately after declaration.
360 |
361 | #### 4.8.3 Arrays
362 |
363 | ##### 4.8.3.1 Array initializers: can be "block-like"
364 |
365 | Any array initializer may optionally be formatted as if it were a "block-like construct." For example, the following are all valid (**not** an exhaustive list):
366 |
367 | ```java
368 | new int[] { new int[] {
369 | 0, 1, 2, 3 0,
370 | } 1,
371 | 2,
372 | new int[] { 3,
373 | 0, 1, }
374 | 2, 3
375 | } new int[]
376 | {0, 1, 2, 3}
377 | ```
378 |
379 | ##### 4.8.3.2 No C-style array declarations
380 |
381 | The square brackets form a part of the type, not the variable: `String[] args`, not `String args[]`.
382 |
383 | #### 4.8.4 Switch statements
384 |
385 | **Terminology Note**: Inside the braces of a switch block are one or more statement groups. Each statement group consists of one or more switch labels (either case FOO: or default:), followed by one or more statements (or, for the last statement group, zero or more statements).
386 |
387 | ##### 4.8.4.1 Indentation
388 |
389 | As with any other block, the contents of a switch block are indented +2.
390 |
391 | After a switch label, there is a line break, and the indentation level is increased +2, exactly as if a block were being opened. The following switch label returns to the previous indentation level, as if a block had been closed.
392 |
393 | ##### 4.8.4.2 Fall-through: commented
394 |
395 | Within a switch block, each statement group either terminates abruptly (with a break, continue, return or thrown exception), or is marked with a comment to indicate that execution will or might continue into the next statement group. Any comment that communicates the idea of fall-through is sufficient (typically // fall through). This special comment is not required in the last statement group of the switch block. Example:
396 |
397 | ```java
398 | switch (input) {
399 | case 1:
400 | case 2:
401 | prepareOneOrTwo();
402 | // fall through
403 | case 3:
404 | handleOneTwoOrThree();
405 | break;
406 | default:
407 | handleLargeNumber(input);
408 | }
409 | ```
410 |
411 | Notice that no comment is needed after case 1:, only at the end of the statement group.
412 |
413 | ##### 4.8.4.3 The default case is present
414 |
415 | Each switch statement includes a `default` statement group, even if it contains no code.
416 |
417 | **Exception**: A switch statement for an `enum` type may omit the `default` statement group, if it includes explicit cases covering all possible values of that type. This enables IDEs or other static analysis tools to issue a warning if any cases were missed.
418 |
419 | #### 4.8.5 Annotations
420 |
421 | Annotations applying to a class, method or constructor appear immediately after the documentation block, and each annotation is listed on a line of its own (that is, one annotation per line). These line breaks do not constitute line-wrapping (Section 4.5, [Line-wrapping](#)), so the indentation level is not increased. Example:
422 |
423 | ```java
424 | @Override
425 | @Nullable
426 | public String getNameIfPresent() { ... }
427 | ```
428 |
429 | **Exception**: A single parameterless annotation may instead appear together with the first line of the signature, for example:
430 |
431 | ```java
432 | @Override public int hashCode() { ... }
433 | ```
434 |
435 | Annotations applying to a field also appear immediately after the documentation block, but in this case, multiple annotations (possibly parameterized) may be listed on the same line; for example:
436 |
437 | ```java
438 | @Partial @Mock DataLoader loader;
439 | ```
440 |
441 | There are no specific rules for formatting annotations on parameters, local variables, or types.
442 |
443 | #### 4.8.6 Comments
444 |
445 | This section addresses implementation comments. Javadoc is addressed separately in Section 7, Javadoc.
446 |
447 | Any line break may be preceded by arbitrary whitespace followed by an implementation comment. Such a comment renders the line non-blank.
448 |
449 | ##### 4.8.6.1 Block comment style
450 |
451 | Block comments are indented at the same level as the surrounding code. They may be in `/* ... */` style or `// ...` style. For multi-line `/* ... */` comments, subsequent lines must start with `*` aligned with the `*` on the previous line.
452 |
453 | ```java
454 | /*
455 | * This is // And so /* Or you can
456 | * okay. // is this. * even do this. */
457 | */
458 | ```
459 |
460 | Comments are not enclosed in boxes drawn with asterisks or other characters.
461 |
462 | **Tip**: When writing multi-line comments, use the `/* ... */` style if you want automatic code formatters to re-wrap the lines when necessary (paragraph-style). Most formatters don't re-wrap lines in `// ...` style comment blocks.
463 |
464 | #### 4.8.7 Modifiers
465 |
466 | Class and member modifiers, when present, appear in the order recommended by the Java Language Specification:
467 |
468 | ```java
469 | public protected private abstract default static final transient volatile synchronized native strictfp
470 | ```
471 |
472 | #### 4.8.8 Numeric Literals
473 |
474 | `long`-valued integer literals use an uppercase `L` suffix, never lowercase (to avoid confusion with the digit `1`). For example, `3000000000L` rather than `3000000000l`.
475 |
476 | ## 5 Naming
477 |
478 | ### 5.1 Rules common to all identifiers
479 |
480 | Identifiers use only ASCII letters and digits, and, in a small number of cases noted below, underscores. Thus each valid identifier name is matched by the regular expression \w+ .
481 |
482 | In Google Style, special prefixes or suffixes are not used. For example, these names are not Google Style: `name_`, `mName`, `s_name` and `kName`.
483 |
484 | ### 5.2 Rules by identifier type
485 |
486 | #### 5.2.1 Package names
487 |
488 | Package names are all lowercase, with consecutive words simply concatenated together (no underscores). For example, `com.example.deepspace`, not `com.example.deepSpace` or `com.example.deep_space`.
489 |
490 | #### 5.2.2 Class names
491 |
492 | Class names are written in [UpperCamelCase](#).
493 |
494 | Class names are typically nouns or noun phrases. For example, `Character` or `ImmutableList`. Interface names may also be nouns or noun phrases (for example, `List`), but may sometimes be adjectives or adjective phrases instead (for example, `Readable`).
495 |
496 | There are no specific rules or even well-established conventions for naming annotation types.
497 |
498 | Test classes are named starting with the name of the class they are testing, and ending with Test. For example, `HashTest` or `HashIntegrationTest`.
499 |
500 | #### 5.2.3 Method names
501 |
502 | Method names are written in [lowerCamelCase](#).
503 |
504 | Method names are typically verbs or verb phrases. For example, `sendMessage` or `stop`.
505 |
506 | Underscores may appear in JUnit test method names to separate logical components of the name, with each component written in [lowerCamelCase](). One typical pattern is `_`, for example `pop_emptyStack`. There is no One Correct Way to name test methods.
507 |
508 | #### 5.2.4 Constant names
509 |
510 | Constant names use `CONSTANT_CASE`: all uppercase letters, with each word separated from the next by a single underscore. But what is a constant, exactly?
511 |
512 | Constants are static final fields whose contents are deeply immutable and whose methods have no detectable side effects. This includes primitives, Strings, immutable types, and immutable collections of immutable types. If any of the instance's observable state can change, it is not a constant. Merely intending to never mutate the object is not enough. Examples:
513 |
514 | ```java
515 | // Constants
516 | static final int NUMBER = 5;
517 | static final ImmutableList NAMES = ImmutableList.of("Ed", "Ann");
518 | static final ImmutableMap AGES = ImmutableMap.of("Ed", 35, "Ann", 32);
519 | static final Joiner COMMA_JOINER = Joiner.on(','); // because Joiner is immutable
520 | static final SomeMutableType[] EMPTY_ARRAY = {};
521 | enum SomeEnum { ENUM_CONSTANT }
522 |
523 | // Not constants
524 | static String nonFinal = "non-final";
525 | final String nonStatic = "non-static";
526 | static final Set mutableCollection = new HashSet();
527 | static final ImmutableSet mutableElements = ImmutableSet.of(mutable);
528 | static final ImmutableMap mutableValues =
529 | ImmutableMap.of("Ed", mutableInstance, "Ann", mutableInstance2);
530 | static final Logger logger = Logger.getLogger(MyClass.getName());
531 | static final String[] nonEmptyArray = {"these", "can", "change"};
532 | ```
533 |
534 | These names are typically nouns or noun phrases.
535 |
536 | #### 5.2.5 Non-constant field names
537 |
538 | Non-constant field names (static or otherwise) are written in `lowerCamelCase`.
539 |
540 | These names are typically nouns or noun phrases. For example, `computedValues` or `index`.
541 |
542 | #### 5.2.6 Parameter names
543 |
544 | Parameter names are written in `lowerCamelCase`.
545 |
546 | One-character parameter names in public methods should be avoided.
547 |
548 | #### 5.2.7 Local variable names
549 |
550 | Local variable names are written in `lowerCamelCase`.
551 |
552 | Even when `final` and immutable, local variables are not considered to be constants, and should not be styled as constants.
553 |
554 | #### 5.2.8 Type variable names
555 |
556 | Each type variable is named in one of two styles:
557 |
558 | A single capital letter, optionally followed by a single numeral (such as `E`, `T`, `X`, `T2`)
559 | A name in the form used for classes (see Section 5.2.2, [Class names](#)), followed by the capital letter `T` (examples: `RequestT`, `FooBarT`).
560 |
561 | ### 5.3 Camel case: defined
562 |
563 | Sometimes there is more than one reasonable way to convert an English phrase into camel case, such as when acronyms or unusual constructs like "`IPv6`" or "`iOS`" are present. To improve predictability, Google Style specifies the following (nearly) deterministic scheme.
564 |
565 | Beginning with the prose form of the name:
566 |
567 | 1. Convert the phrase to plain ASCII and remove any apostrophes. For example, "Müller's algorithm" might become "Muellers algorithm".
568 | 2. Divide this result into words, splitting on spaces and any remaining punctuation (typically hyphens).
569 | - **Recommended**: if any word already has a conventional camel-case appearance in common usage, split this into its constituent parts (e.g., "AdWords" becomes "ad words"). Note that a word such as "iOS" is not really in camel case per se; it defies any convention, so this recommendation does not apply.
570 | 3. Now lowercase everything (including acronyms), then uppercase only the first character of:
571 | - each word, to yield upper camel case, or
572 | - each word except the first, to yield lower camel case
573 | 4. Finally, join all the words into a single identifier.
574 |
575 | Note that the casing of the original words is almost entirely disregarded. Examples:
576 |
577 | | Prose form | Correct | Incorrect |
578 | | ------------ | ------------ | ------------ |
579 | | "XML HTTP request" | XmlHttpRequest | XMLHTTPRequest |
580 | | "new customer ID" | newCustomerId | newCustomerID |
581 | | "inner stopwatch" | innerStopwatch | innerStopWatch |
582 | | "supports IPv6 on iOS?" | supportsIpv6OnIos | supportsIPv6OnIOS |
583 | | "YouTube importer" | YouTubeImporter YoutubeImporter* | 无 |
584 |
585 | Note: Some words are ambiguously hyphenated in the English language: for example "nonempty" and "non-empty" are both correct, so the method names `checkNonempty` and `checkNonEmpty` are likewise both correct.
586 |
587 | ## 6 Programming Practices
588 |
589 | ### 6.1 @Override: always used
590 |
591 | A method is marked with the `@Override` annotation whenever it is legal. This includes a class method overriding a superclass method, a class method implementing an interface method, and an interface method respecifying a superinterface method.
592 |
593 | **Exception**: `@Override` may be omitted when the parent method is @Deprecated.
594 |
595 | ### 6.2 Caught exceptions: not ignored
596 |
597 | Except as noted below, it is very rarely correct to do nothing in response to a caught exception. (Typical responses are to log it, or if it is considered "impossible", rethrow it as an `AssertionError`.)
598 |
599 | When it truly is appropriate to take no action whatsoever in a catch block, the reason this is justified is explained in a comment.
600 |
601 | ```java
602 | try {
603 | int i = Integer.parseInt(response);
604 | return handleNumericResponse(i);
605 | } catch (NumberFormatException ok) {
606 | // it's not numeric; that's fine, just continue
607 | }
608 | return handleTextResponse(response);
609 | ```
610 |
611 | **Exception**: In tests, a caught exception may be ignored without comment if its name is or begins with `expected`. The following is a very common idiom for ensuring that the code under test does throw an exception of the expected type, so a comment is unnecessary here.
612 |
613 | ```java
614 | try {
615 | emptyStack.pop();
616 | fail();
617 | } catch (NoSuchElementException expected) {
618 | }
619 | ```
620 |
621 | ### 6.3 Static members: qualified using class
622 |
623 | When a reference to a static class member must be qualified, it is qualified with that class's name, not with a reference or expression of that class's type.
624 |
625 | ```java
626 | Foo aFoo = ...;
627 | Foo.aStaticMethod(); // good
628 | aFoo.aStaticMethod(); // bad
629 | somethingThatYieldsAFoo().aStaticMethod(); // very bad
630 | ```
631 |
632 | ### 6.4 Finalizers: not used
633 |
634 | It is **extremely rare** to override `Object.finalize`.
635 |
636 | > **Tip**: Don't do it. If you absolutely must, first read and understand [Effective Java Item 7](http://books.google.com/books?isbn=8131726592), "Avoid Finalizers," very carefully, and then don't do it.
637 |
638 | ## 7 Javadoc
639 |
640 | ### 7.1 Formatting
641 |
642 | #### 7.1.1 General form
643 |
644 | The basic formatting of Javadoc blocks is as seen in this example:
645 |
646 | ```java
647 | /**
648 | * 这里写了多行 Javadoc 文本,
649 | * 正常包裹...
650 | */
651 | public int method(String p1) { ... }
652 | ```
653 |
654 | ... or in this single-line example:
655 |
656 | ```java
657 | /** An especially short bit of Javadoc. */
658 | ```
659 |
660 | The basic form is always acceptable. The single-line form may be substituted when the entirety of the Javadoc block (including comment markers) can fit on a single line. Note that this only applies when there are no block tags such as `@return`.
661 |
662 | #### 7.1.2 Paragraphs
663 |
664 | One blank line—that is, a line containing only the aligned leading asterisk (`*`)—appears between paragraphs, and before the group of block tags if present. Each paragraph but the first has `
` immediately before the first word, with no space after.
665 |
666 | #### 7.1.3 Block tags
667 |
668 | Any of the standard "block tags" that are used appear in the order `@param`, `@return`, `@throws`, `@deprecated`, and these four types never appear with an empty description. When a block tag doesn't fit on a single line, continuation lines are indented `four` (or more) spaces from the position of the `@`.
669 |
670 | ### 7.2 The summary fragment
671 |
672 | Each Javadoc block begins with a brief **summary fragment**. This fragment is very important: it is the only part of the text that appears in certain contexts such as class and method indexes.
673 |
674 | This is a fragment—a noun phrase or verb phrase, not a complete sentence. It does not begin with `A {@code Foo} is a...`, or `This method returns...`, nor does it form a complete imperative sentence like `Save the record.`. However, the fragment is capitalized and punctuated as if it were a complete sentence.
675 |
676 | Tip: A common mistake is to write simple Javadoc in the form `/** @return the customer ID */`. This is incorrect, and should be changed to `/** Returns the customer ID. */`.
677 |
678 | ### 7.3 Where Javadoc is used
679 |
680 | At the minimum, Javadoc is present for every `public` class, and every `public` or `protected` member of such a class, with a few exceptions noted below.
681 |
682 | Additional Javadoc content may also be present, as explained in Section 7.3.4, [Non-required Javadoc](#).
683 |
684 | #### 7.3.1 Exception: self-explanatory methods
685 |
686 | Javadoc is optional for "simple, obvious" methods like getFoo, in cases where there really and truly is nothing else worthwhile to say but "`Returns the foo`".
687 |
688 | Important: it is not appropriate to cite this exception to justify omitting relevant information that a typical reader might need to know. For example, for a method named `getCanonicalName`, don't omit its documentation (with the rationale that it would say only `/** Returns the canonical name. */`) if a typical reader may have no idea what the term "canonical name" means!
689 |
690 | #### 7.3.2 Exception: overrides
691 |
692 | Javadoc is not always present on a method that overrides a supertype method.
693 |
694 | #### 7.3.4 Non-required Javadoc
695 |
696 | Other classes and members have Javadoc as needed or desired.
697 |
698 | Whenever an implementation comment would be used to define the overall purpose or behavior of a class or member, that comment is written as Javadoc instead (using `/**`).
699 |
700 | Non-required Javadoc is not strictly required to follow the formatting rules of Sections 7.1.2, 7.1.3, and 7.2, though it is of course recommended.
701 |
--------------------------------------------------------------------------------
/docs/index.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |