http://www.hawstein.com/posts/google-java-style.htmlhtml
这份文档是Google Java编程风格规范的完整定义。当且仅当一个Java源文件符合此文档中的规则,咱们才认为它符合Google的Java编程风格。java
与其它的编程风格指南同样,这里所讨论的不只仅是编码格式美不美观的问题,同时也讨论一些约定及编码标准。然而,这份文档主要侧重于咱们所广泛遵循的规则,对于那些不是明确强制要求的,咱们尽可能避免提供意见。android
在本文档中,除非另有说明:程序员
@interface
)其余的术语说明会偶尔在后面的文档出现。正则表达式
本文档中的示例代码并不做为规范。也就是说,虽然示例代码是遵循Google编程风格,但并不意味着这是展示这些代码的惟一方式。示例中的格式选择不该该被强制定为规则。shell
源文件以其最顶层的类名来命名,大小写敏感,文件扩展名为.java
。编程
源文件编码格式为UTF-8。数组
除了行结束符序列,ASCII水平空格字符(0x20,即空格)是源文件中惟一容许出现的空白字符,这意味着:app
对于具备特殊转义序列的任何字符(\b, \t, \n, \f, \r, ", '及\),咱们使用它的转义序列,而不是相应的八进制(好比\012
)或Unicode(好比\u000a
)转义。框架
对于剩余的非ASCII字符,是使用实际的Unicode字符(好比∞),仍是使用等价的Unicode转义符(好比\u221e),取决于哪一个能让代码更易于阅读和理解。
Tip: 在使用Unicode转义符或是一些实际的Unicode字符时,建议作些注释给出解释,这有助于别人阅读和理解。
例如:
String unitAbbrev = "μs"; | 赞,即便没有注释也很是清晰 String unitAbbrev = "\u03bcs"; // "μs" | 容许,但没有理由要这样作 String unitAbbrev = "\u03bcs"; // Greek letter mu, "s" | 容许,但这样作显得笨拙还容易出错 String unitAbbrev = "\u03bcs"; | 很糟,读者根本看不出这是什么 return '\ufeff' + content; // byte order mark | Good,对于非打印字符,使用转义,并在必要时写上注释
Tip: 永远不要因为惧怕某些程序可能没法正确处理非ASCII字符而让你的代码可读性变差。当程序没法正确处理非ASCII字符时,它天然没法正确运行,你就会去fix这些问题的了。(言下之意就是大胆去用非ASCII字符,若是真的有须要的话)
一个源文件包含(按顺序地):
以上每一个部分之间用一个空行隔开。
若是一个文件包含许可证或版权信息,那么它应当被放在文件最前面。
package语句不换行,列限制(4.4节)并不适用于package语句。(即package语句写在一行里)
即,不要出现相似这样的import语句:import java.util.*;
import语句不换行,列限制(4.4节)并不适用于import语句。(每一个import语句独立成行)
import语句可分为如下几组,按照这个顺序,每组由一个空行分隔:
com.google
imports(仅当这个源文件是在com.google
包下)java
importsjavax
imports组内不空行,按字典序排列。
每一个顶级类都在一个与它同名的源文件中(固然,还包含.java
后缀)。
例外:package-info.java
,该文件中可没有package-info
类。
类的成员顺序对易学性有很大的影响,但这也不存在惟一的通用法则。不一样的类对成员的排序多是不一样的。最重要的一点,每一个类应该以某种逻辑去排序它的成员,维护者应该要能解释这种排序逻辑。好比,新的方法不能老是习惯性地添加到类的结尾,由于这样就是按时间顺序而非某种逻辑来排序的。
当一个类有多个构造函数,或是多个同名方法,这些函数/方法应该按顺序出如今一块儿,中间不要放进其它函数/方法。
术语说明:块状结构(block-like construct)指的是一个类,方法或构造函数的主体。须要注意的是,数组初始化中的初始值可被选择性地视为块状结构(4.8.3.1节)。
大括号与if, else, for, do, while
语句一块儿使用,即便只有一条语句(或是空),也应该把大括号写上。
对于非空块和块状结构,大括号遵循Kernighan和Ritchie风格 (Egyptian brackets):
示例:
return new MyClass() { @Override public void method() { if (condition()) { try { something(); } catch (ProblemException e) { recover(); } } } };
4.8.1节给出了enum类的一些例外。
一个空的块状结构里什么也不包含,大括号能够简洁地写成{}
,不须要换行。例外:若是它是一个多块语句的一部分(if/else 或 try/catch/finally) ,即便大括号内没内容,右大括号也要换行。
示例:
void doNothing() {}
每当开始一个新的块,缩进增长2个空格,当块结束时,缩进返回先前的缩进级别。缩进级别适用于代码和注释。(见4.1.2节中的代码示例)
每一个语句后要换行。
一个项目能够选择一行80个字符或100个字符的列限制,除了下述例外,任何一行若是超过这个字符数限制,必须自动换行。
例外:
package
和import
语句(见3.2节和3.3节)。术语说明:通常状况下,一行长代码为了不超出列限制(80或100个字符)而被分为多行,咱们称之为自动换行(line-wrapping)。
咱们并无全面,肯定性的准则来决定在每一种状况下如何自动换行。不少时候,对于同一段代码会有好几种有效的自动换行方式。
Tip: 提取方法或局部变量能够在不换行的状况下解决代码过长的问题(是合理缩短命名长度吧)
自动换行的基本准则是:更倾向于在更高的语法级别处断开。
非赋值运算符
处断开,那么在该符号前断开(好比+,它将位于下一行)。注意:这一点与Google其它语言的编程风格不一样(如C++和JavaScript)。这条规则也适用于如下“类运算符”符号:点分隔符(.),类型界限中的&(<T extends Foo & Bar>
),catch块中的管道符号(catch (FooException | BarException e
)赋值运算符
处断开,一般的作法是在该符号后断开(好比=,它与前面的内容留在同一行)。这条规则也适用于foreach
语句中的分号。自动换行时,第一行后的每一行至少比第一行多缩进4个空格(注意:制表符不用于缩进。见2.3.1节)。
当存在连续自动换行时,缩进可能会多缩进不仅4个空格(语法元素存在多级时)。通常而言,两个连续行使用相同的缩进当且仅当它们开始于同级语法元素。
第4.6.3水平对齐一节中指出,不鼓励使用可变数目的空格来对齐前面行的符号。
如下状况须要使用一个空行:
多个连续的空行是容许的,但没有必要这样作(咱们也不鼓励这样作)。
除了语言需求和其它规则,而且除了文字,注释和Javadoc用到单个空格,单个ASCII空格也出如今如下几个地方:
(
)(如if, for catch
等)。}
)(如else, catch
)。{
),两个例外:
@SomeAnnotation({a, b})
(不使用空格)。String[][] x = foo;
(大括号间没有空格,见下面的Note)。<T extends Foo & Bar>
)。catch (FooException | BarException e
)。foreach
语句中的分号。, : ;
及右括号()
)后new int[] {5, 6}
和new int[] { 5, 6 }
都是能够的。Note:这个规则并不要求或禁止一行的开关或结尾须要额外的空格,只对内部空格作要求。
术语说明:水平对齐指的是经过增长可变数量的空格来使某一行的字符与上一行的相应字符对齐。
这是容许的(并且在很多地方能够看到这样的代码),但Google编程风格对此不作要求。即便对于已经使用水平对齐的代码,咱们也不须要去保持这种风格。
如下示例先展现未对齐的代码,而后是对齐的代码:
private int x; // this is fine private Color color; // this too private int x; // permitted, but future edits private Color color; // may leave it unaligned
Tip:对齐可增长代码可读性,但它为往后的维护带来问题。考虑将来某个时候,咱们须要修改一堆对齐的代码中的一行。这可能致使本来很漂亮的对齐代码变得错位。极可能它会提示你调整周围代码的空白来使这一堆代码从新水平对齐(好比程序员想保持这种水平对齐的风格),这就会让你作许多的无用功,增长了reviewer的工做而且可能致使更多的合并冲突。
除非做者和reviewer都认为去掉小括号也不会使代码被误解,或是去掉小括号能让代码更易于阅读,不然咱们不该该去掉小括号。咱们没有理由假设读者能记住整个Java运算符优先级表。
枚举常量间用逗号隔开,换行可选。
没有方法和文档的枚举类可写成数组初始化的格式:
private enum Suit { CLUBS, HEARTS, SPADES, DIAMONDS }
因为枚举类也是一个类,所以全部适用于其它类的格式规则也适用于枚举类。
不要使用组合声明,好比int a, b;
。
不要在一个代码块的开头把局部变量一次性都声明了(这是c语言的作法),而是在第一次须要使用它时才声明。局部变量在声明时最好就进行初始化,或者声明后尽快进行初始化。
数组初始化能够写成块状结构,好比,下面的写法都是OK的:
new int[] { 0, 1, 2, 3 } new int[] { 0, 1, 2, 3 } new int[] { 0, 1, 2, 3 } new int[]{0, 1, 2, 3}
中括号是类型的一部分:String[] args
, 而非String args[]
。
术语说明:switch块的大括号内是一个或多个语句组。每一个语句组包含一个或多个switch标签(case FOO:
或default:
),后面跟着一条或多条语句。
与其它块状结构一致,switch块中的内容缩进为2个空格。
每一个switch标签后新起一行,再缩进2个空格,写下一条或多条语句。
在一个switch块内,每一个语句组要么经过break, continue, return
或抛出异常来终止,要么经过一条注释来讲明程序将继续执行到下一个语句组,任何能表达这个意思的注释都是OK的(典型的是用// fall through
)。这个特殊的注释并不须要在最后一个语句组(通常是default
)中出现。示例:
switch (input) { case 1: case 2: prepareOneOrTwo(); // fall through case 3: handleOneTwoOrThree(); break; default: handleLargeNumber(input); }
每一个switch语句都包含一个default
语句组,即便它什么代码也不包含。
注解紧跟在文档块后面,应用于类、方法和构造函数,一个注解独占一行。这些换行不属于自动换行(第4.5节,自动换行),所以缩进级别不变。例如:
@Override @Nullable public String getNameIfPresent() { ... }
例外:单个的注解能够和签名的第一行出如今同一行。例如:
@Override public int hashCode() { ... }
应用于字段的注解紧随文档块出现,应用于字段的多个注解容许与字段出如今同一行。例如:
@Partial @Mock DataLoader loader;
参数和局部变量注解没有特定规则。
块注释与其周围的代码在同一缩进级别。它们能够是/* ... */
风格,也能够是// ...
风格。对于多行的/* ... */
注释,后续行必须从*
开始,而且与前一行的*
对齐。如下示例注释都是OK的。
/* * This is // And so /* Or you can * okay. // is this. * even do this. */ */
注释不要封闭在由星号或其它字符绘制的框架里。
Tip:在写多行注释时,若是你但愿在必要时能从新换行(即注释像段落风格同样),那么使用
/* ... */
。
类和成员的modifiers若是存在,则按Java语言规范中推荐的顺序出现。
public protected private abstract static final transient volatile synchronized native strictfp
标识符只能使用ASCII字母和数字,所以每一个有效的标识符名称都能匹配正则表达式\w+
。
在Google其它编程语言风格中使用的特殊前缀或后缀,如name_
, mName
, s_name
和kName
,在Java编程风格中都再也不使用。
包名所有小写,连续的单词只是简单地链接起来,不使用下划线。
类名都以UpperCamelCase
风格编写。
类名一般是名词或名词短语,接口名称有时多是形容词或形容词短语。如今尚未特定的规则或行之有效的约定来命名注解类型。
测试类的命名以它要测试的类的名称开始,以Test
结束。例如,HashTest
或HashIntegrationTest
。
方法名都以lowerCamelCase
风格编写。
方法名一般是动词或动词短语。
下划线可能出如今JUnit测试方法名称中用以分隔名称的逻辑组件。一个典型的模式是:test<MethodUnderTest>_<state>
,例如testPop_emptyStack
。并不存在惟一正确的方式来命名测试方法。
常量名命名模式为CONSTANT_CASE
,所有字母大写,用下划线分隔单词。那,到底什么算是一个常量?
每一个常量都是一个静态final字段,但不是全部静态final字段都是常量。在决定一个字段是不是一个常量时,考虑它是否真的感受像是一个常量。例如,若是任何一个该实例的观测状态是可变的,则它几乎确定不会是一个常量。只是永远不打算
改变对象通常是不够的,它要真的一直不变才能将它示为常量。
// Constants static final int NUMBER = 5; static final ImmutableList<String> NAMES = ImmutableList.of("Ed", "Ann"); static final Joiner COMMA_JOINER = Joiner.on(','); // because Joiner is immutable static final SomeMutableType[] EMPTY_ARRAY = {}; enum SomeEnum { ENUM_CONSTANT } // Not constants static String nonFinal = "non-final"; final String nonStatic = "non-static"; static final Set<String> mutableCollection = new HashSet<String>(); static final ImmutableSet<SomeMutableType> mutableElements = ImmutableSet.of(mutable); static final Logger logger = Logger.getLogger(MyClass.getName()); static final String[] nonEmptyArray = {"these", "can", "change"};
这些名字一般是名词或名词短语。
很是量字段名以lowerCamelCase
风格编写。
这些名字一般是名词或名词短语。
参数名以lowerCamelCase
风格编写。
参数应该避免用单个字符命名。
局部变量名以lowerCamelCase
风格编写,比起其它类型的名称,局部变量名能够有更为宽松的缩写。
虽然缩写更宽松,但仍是要避免用单字符进行命名,除了临时变量和循环变量。
即便局部变量是final和不可改变的,也不该该把它示为常量,天然也不能用常量的规则去命名它。
类型变量可用如下两种风格之一进行命名:
驼峰式命名法分大驼峰式命名法(UpperCamelCase
)和小驼峰式命名法(lowerCamelCase
)。有时,咱们有不仅一种合理的方式将一个英语词组转换成驼峰形式,如缩略语或不寻常的结构(例如”IPv6”或”iOS”)。Google指定了如下的转换方案。
名字从散文形式
(prose form)开始:
示例:
Prose form Correct Incorrect
------------------------------------------------------------------
"XML HTTP request" XmlHttpRequest XMLHTTPRequest
"new customer ID" newCustomerId newCustomerID
"inner stopwatch" innerStopwatch innerStopWatch
"supports IPv6 on iOS?" supportsIpv6OnIos supportsIPv6OnIOS
"YouTube importer" YouTubeImporter
YoutubeImporter*
加星号处表示能够,但不推荐。
Note:在英语中,某些带有连字符的单词形式不惟一。例如:”nonempty”和”non-empty”都是正确的,所以方法名
checkNonempty
和checkNonEmpty
也都是正确的。
只要是合法的,就把@Override
注解给用上。
除了下面的例子,对捕获的异常不作响应是极少正确的。(典型的响应方式是打印日志,或者若是它被认为是不可能的,则把它看成一个AssertionError
从新抛出。)
若是它确实是不须要在catch块中作任何响应,须要作注释加以说明(以下面的例子)。
try { int i = Integer.parseInt(response); return handleNumericResponse(i); } catch (NumberFormatException ok) { // it's not numeric; that's fine, just continue } return handleTextResponse(response);
例外:在测试中,若是一个捕获的异常被命名为expected
,则它能够被不加注释地忽略。下面是一种很是常见的情形,用以确保所测试的方法会抛出一个指望中的异常,所以在这里就没有必要加注释。
try { emptyStack.pop(); fail(); } catch (NoSuchElementException expected) { }
使用类名调用静态的类成员,而不是具体某个对象或表达式。
Foo aFoo = ...; Foo.aStaticMethod(); // good aFoo.aStaticMethod(); // bad somethingThatYieldsAFoo().aStaticMethod(); // very bad
极少会去重写Object.finalize
。
Tip:不要使用finalize。若是你非要使用它,请先仔细阅读和理解Effective Java 第7条款:“Avoid Finalizers”,而后不要使用它。
Javadoc块的基本格式以下所示:
/** * Multiple lines of Javadoc text are written here, * wrapped normally... */ public int method(String p1) { ... }
或者是如下单行形式:
/** An especially short bit of Javadoc. */
基本格式老是OK的。当整个Javadoc块能容纳于一行时(且没有Javadoc标记@XXX),可使用单行形式。
空行(即,只包含最左侧星号的行)会出如今段落之间和Javadoc标记(@XXX)以前(若是有的话)。除了第一个段落,每一个段落第一个单词前都有标签<p>
,而且它和第一个单词间没有空格。
标准的Javadoc标记按如下顺序出现:@param
, @return
, @throws
, @deprecated
, 前面这4种标记若是出现,描述都不能为空。当描述没法在一行中容纳,连续行须要至少再缩进4个空格。
每一个类或成员的Javadoc以一个简短的摘要片断开始。这个片断是很是重要的,在某些状况下,它是惟一出现的文本,好比在类和方法索引中。
这只是一个小片断,能够是一个名词短语或动词短语,但不是一个完整的句子。它不会以A {@code Foo} is a...
或This method returns...
开头, 它也不会是一个完整的祈使句,如Save the record...
。然而,因为开头大写及被加了标点,它看起来就像是个完整的句子。
Tip:一个常见的错误是把简单的Javadoc写成
/** @return the customer ID */
,这是不正确的。它应该写成/** Returns the customer ID. */
。
至少在每一个public类及它的每一个public和protected成员处使用Javadoc,如下是一些例外:
对于简单明显的方法如getFoo
,Javadoc是可选的(即,是能够不写的)。这种状况下除了写“Returns the foo”,确实也没有什么值得写了。
单元测试类中的测试方法多是不言自明的最多见例子了,咱们一般能够从这些方法的描述性命名中知道它是干什么的,所以不须要额外的文档说明。
Tip:若是有一些相关信息是须要读者了解的,那么以上的例外不该做为忽视这些信息的理由。例如,对于方法名
getCanonicalName
,就不该该忽视文档说明,由于读者极可能不知道词语canonical name
指的是什么。
若是一个方法重写了超类中的方法,那么Javadoc并不是必需的。
对于包外不可见的类和方法,若有须要,也是要使用Javadoc的。若是一个注释是用来定义一个类,方法,字段的总体目的或行为,那么这个注释应该写成Javadoc,这样更统一更友好。