diff --git a/eclipse-java-google-style.xml b/eclipse-java-google-style.xml index 848c150..08d930a 100644 --- a/eclipse-java-google-style.xml +++ b/eclipse-java-google-style.xml @@ -1,7 +1,8 @@ - - + + + @@ -9,11 +10,13 @@ - - + + + + @@ -21,53 +24,59 @@ - + - - - + + + + + + - + + + - + - + + + - - + - + - + - + @@ -76,35 +85,43 @@ - + + + + + + - + + - + + + @@ -118,26 +135,33 @@ + + + - - + - + + + + + + @@ -151,13 +175,15 @@ - - + + - - + + + + @@ -169,42 +195,52 @@ - + + - - + + - + - + + - - + + + + - - - + + + + + + + - - + + + + @@ -214,11 +250,11 @@ - + + - @@ -231,58 +267,68 @@ + - + + - + - + - + + - + - - - + + + + + - + - + + - + + + + + diff --git a/javaguide.html b/javaguide.html index 3588367..610c7ce 100644 --- a/javaguide.html +++ b/javaguide.html @@ -10,7 +10,7 @@

Google Java Style

-
Last changed: December 19, 2013
+
Last changed: February 03, 2014
@@ -154,6 +154,9 @@
4.8.7 Modifiers
+
+4.8.8 Numeric Literals +
@@ -266,7 +269,7 @@ code. Optional formatting choices made in examples should not be enforced as rul

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).

+plus the .java extension.

2.2 File encoding: UTF-8 

Source files are encoded in UTF-8.

2.3 Special characters 

@@ -325,8 +328,7 @@ ASCII sort order; the presence of semicolons warps the result.)

3.4.1 Exactly one top-level class declaration 

-

Each top-level class resides in a source file of its own.

Exception:  of course, no such class appears in package-info.java -files.

+

Each top-level class resides in a source file of its own.

3.4.2 Class member ordering 

The ordering of the members of a class can have a great effect on learnability, but there is no single correct recipe for how to do it. Different classes may order their members @@ -494,8 +496,8 @@ private enum Suit { CLUBS, HEARTS, SPADES, DIAMONDS }

4.8.2 Variable declarations 

4.8.2.1 One variable per declaration 
-

Combined declarations such as int a, b; are -not used.

+

Every variable declaration (field or local) declares only one variable: declarations such as +int a, b; are not used.
4.8.2.2 Declared when needed, initialized as soon as possible 

Local variables are not habitually declared at the start of their containing @@ -593,7 +595,11 @@ re-wrap the lines when necessary (paragraph-style). Most formatters don't re-wra recommended by the Java Language Specification: 

 public protected private abstract static final transient volatile synchronized native strictfp
-
+ +

4.8.8 Numeric Literals 

+

long-valued integer literals use an uppercase L suffix, never +lowercase (to avoid confusion with the digit 1). For example, 3000000000L +rather than 3000000000l.

5 Naming 

5.1 Rules common to all identifiers 

@@ -607,16 +613,23 @@ suffixes, like those seen in the examples

5.2.1 Package names 

Package names are all lowercase, with consecutive words simply concatenated together (no -underscores).

+underscores). For example, com.example.deepspace, not +com.example.deepSpace or +com.example.deep_space.

5.2.2 Class names 

-

Class names are written in UpperCamelCase.

Class names are typically nouns or noun phrases. Interface names may sometimes be adjectives or -adjective phrases instead. There are no specific rules or even well-established conventions for -naming annotation types.

Test classes are named starting with the name of the class they are testing, and ending +

Class names are written in UpperCamelCase.

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).

There are no specific rules or even well-established conventions for naming annotation types.

Test classes are named starting with the name of the class they are testing, and ending with Test. For example, HashTest or HashIntegrationTest.

5.2.3 Method names 

-

Method names are written in lowerCamelCase.

Method names are typically verbs or verb phrases.

Underscores may appear in JUnit test method names to separate logical components of the +

Method names are written in lowerCamelCase.

Method names are typically verbs or verb phrases. For example, +sendMessage or +stop.

Underscores may appear in JUnit test method names to separate logical components of the name. One typical pattern is test<MethodUnderTest>_<state>, for example testPop_emptyStack. There is no One Correct Way to name test methods.

@@ -644,7 +657,9 @@ static final String[] nonEmptyArray = {"these", "can", "change"};

These names are typically nouns or noun phrases.

5.2.5 Non-constant field names 

Non-constant field names (static or otherwise) are written -in lowerCamelCase.

These names are typically nouns or noun phrases.

+in lowerCamelCase.

These names are typically nouns or noun phrases. For example, +computedValues or +index.

5.2.6 Parameter names 

Parameter names are written in lowerCamelCase.

One-character parameter names should be avoided.

5.2.7 Local variable names 

@@ -679,8 +694,10 @@ predictability, Google Style specifies the following (nearly) deterministic sche

6 Programming Practices 

6.1 @Override: always used 

-

The @Override annotation is used in any context in -which it is legal.

+

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.

6.2 Caught exceptions: not ignored 

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 @@ -720,7 +737,7 @@ Item 7, "Avoid Finalizers," very carefully, and then don't do it.

7.1 Formatting 

7.1.1 General form 

-

The basic formatting of Javadoc blocks is as seen in this general example:

+    
The basic formatting of Javadoc blocks is as seen in this example:
 /**
  * Multiple lines of Javadoc text are written here,
  * wrapped normally...
@@ -728,7 +745,7 @@ Item 7, "Avoid Finalizers," very carefully, and then don't do it.
... or in this single-line example:
 /** An especially short bit of Javadoc. */
-
The general form is always acceptable. The single-line form may be substituted when there are no
+
The basic form is always acceptable. The single-line form may be substituted when there are no
 at-clauses present, and the entirety of the Javadoc block (including comment markers) can fit on a
 single line.

     
7.1.2 Paragraphs 

@@ -778,6 +795,6 @@ means!

 needed. Whenever an implementation comment would be used to define the overall purpose or
 behavior of a class, method or field, that comment is written as Javadoc instead. (It's more
 uniform, and more tool-friendly.)
  

-  
Last changed: December 19, 2013

+  
Last changed: February 03, 2014