没有合适的资源?快使用搜索试试~ 我知道了~
首页Google Java Code Style Guide
Google的Java编码规范 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.
资源详情
资源评论
资源推荐
Google Java Style
Last changed: December 19, 2013
1 Introduction
1.1 Terminology notes
1.2 Guide notes
2 Source file basics
2.1 File name
2.2 File encoding: UTF-8
2.3 Special characters
2.3.1 Whitespace
characters
2.3.2 Special escape
sequences
2.3.3 Non-ASCII
characters
3 Source file structure
3.1 License or copyright
information, if present
3.2 Package statement
3.3 Import statements
3.3.1 No wildcard
imports
3.3.2 No line-wrapping
3.3.3 Ordering and
spacing
3.4 Class declaration
3.4.1 Exactly one top-
level class declaration
3.4.2 Class member
ordering
4 Formatting
4.1 Braces
4.1.1 Braces are used
where optional
4.1.2 Nonempty blocks:
K & R style
4.1.3 Empty blocks: may
be concise
4.2 Block indentation: +2
spaces
4.3 One statement per line
4.4 Column limit: 80 or 100
4.5 Line-wrapping
4.5.1 Where to break
4.5.2 Indent continuation
lines at least +4 spaces
4.6 Whitespace
4.6.1 Vertical
Whitespace
4.6.2 Horizontal
whitespace
4.6.3 Horizontal
alignment: never required
4.7 Grouping parentheses:
recommended
4.8 Specific constructs
4.8.1 Enum classes
4.8.2 Variable
declarations
4.8.3 Arrays
4.8.4 Switch statements
4.8.5 Annotations
4.8.6 Comments
4.8.7 Modifiers
5 Naming
5.1 Rules common to all
identifiers
5.2 Rules by identifier
type
5.2.1 Package
names
5.2.2 Class names
5.2.3 Method names
5.2.4 Constant
names
5.2.5 Non-constant
field names
5.2.6 Parameter
names
5.2.7 Local variable
names
5.2.8 Type variable
names
5.3 Camel case: defined
6 Programming Practices
6.1 @Override: always
used
6.2 Caught exceptions:
not ignored
6.3 Static members:
qualified using class
6.4 Finalizers: not used
7 Javadoc
7.1 Formatting
7.1.1 General form
7.1.2 Paragraphs
7.1.3 At-clauses
7.2 The summary
fragment
7.3 Where Javadoc is
used
7.3.1 Exception: self-
explanatory methods
7.3.2 Exception:
overrides
7.3.3 Optional
javadoc
1 Introduction
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.
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).
1.1 Terminology notes
In this document, unless otherwise clarified:
1. The term class is used inclusively to mean an "ordinary" class, enum class, interface
or annotation type ( @interface).
2. The term comment always refers to implementation comments. We do not use the
phrase "documentation comments", instead using the common term "Javadoc."
Other "terminology notes" will appear occasionally throughout the document.
1.2 Guide notes
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.
2 Source file basics
2.1 File name
The source file name consists of the case-sensitive name of the top-level class it contains,
plus the .java extension (aside from package-info.java files).
2.2 File encoding: UTF-8
Source files are encoded in UTF-8.
2.3 Special characters
2.3.1 Whitespace characters
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:
1. All other whitespace characters in string and character literals are escaped.
2. Tab characters are not used for indentation.
2.3.2 Special escape sequences
For any character that has a special escape sequence ( \b, \t, \n, \f, \r, \",
\' and \\), that sequence is used rather than the corresponding octal (e.g. \012) or
Unicode (e.g. \u000a) escape.
2.3.3 Non-ASCII characters
For the remaining non-ASCII characters, either the actual Unicode character (e.g. ∞ ) or
the equivalent Unicode escape (e.g. \u221e) is used, depending only on which makes the
code easier to read and understand.
Tip: in the Unicode escape case, and occasionally even when actual Unicode characters
are used, an explanatory comment can be very helpful.
Examples:
Example Discussion
String unitAbbrev = "μs";
Best: perfectly clear
even without a
comment.
String unitAbbrev = "\u03bcs"; // "μs"
Allowed, but there's
no reason to do this.
String unitAbbrev = "\u03bcs"; // Greek letter mu, "s"
Allowed, but
awkward and prone
to mistakes.
String unitAbbrev = "\u03bcs";
Poor: the reader has
no idea what this is.
return '\ufeff' + content; // byte order mark
Good: use escapes
for non-printable
characters, and
comment if
necessary.
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.
3 Source file structure
A source file consists of, in order:
1. License or copyright information, if present
2. Package statement
3. Import statements
4. Exactly one top-level class
Exactly one blank line separates each section that is present.
3.1 License or copyright information, if present
If license or copyright information belongs in a file, it belongs here.
3.2 Package statement
The package statement is not line-wrapped. The column limit (Section 4.4, Column limit:
80 or 100) does not apply to package statements.
3.3 Import statements
3.3.1 No wildcard imports
Wildcard imports, static or otherwise, are not used.
3.3.2 No line-wrapping
Import statements are not line-wrapped. The column limit (Section 4.4, Column limit: 80 or
100) does not apply to import statements.
3.3.3 Ordering and spacing
Import statements are divided into the following groups, in this order, with each group
separated by a single blank line:
1. All static imports in a single group
2. com.google imports (only if this source file is in the com.google package
space)
3. Third-party imports, one group per top-level package, in ASCII sort order
for example: android, com, junit, org, sun
4. java imports
5. javax imports
Within a group there are no blank lines, and the imported names appear in ASCII sort order.
(Note: this is not the same as the import statements being in ASCII sort order; the presence
of semicolons warps the result.)
剩余17页未读,继续阅读
cobra_cai
- 粉丝: 1
- 资源: 15
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- ExcelVBA中的Range和Cells用法说明.pdf
- 基于单片机的电梯控制模型设计.doc
- 主成分分析和因子分析.pptx
- 共享笔记服务系统论文.doc
- 基于数据治理体系的数据中台实践分享.pptx
- 变压器的铭牌和额定值.pptx
- 计算机网络课程设计报告--用winsock设计Ping应用程序.doc
- 高电压技术课件:第03章 液体和固体介质的电气特性.pdf
- Oracle商务智能精华介绍.pptx
- 基于单片机的输液滴速控制系统设计文档.doc
- dw考试题 5套.pdf
- 学生档案管理系统详细设计说明书.doc
- 操作系统PPT课件.pptx
- 智慧路边停车管理系统方案.pptx
- 【企业内控系列】企业内部控制之人力资源管理控制(17页).doc
- 温度传感器分类与特点.pptx
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0