AppPerfect

Java Code Naming Convention 

Rules available in this category:

1. Variable_names_in_uppercase_should_be_made_final
2. Avoid_naming_types_having_same_names_as_java_lang_types
3. Use_proper_naming_convention_for_non_static_fields
4. Avoid_local_variables_names_differing_only_in_case
5. Avoid_method_parameter_names_differing_only_in_case
6. Use_proper_naming_convention_for_tag_handlers_and_associated_classes
7. Use_proper_naming_convention_for_utility_classes
8. Use_proper_naming_convention_for_getters
9. Use_proper_naming_convention_for_setters
10. Avoid_field_name_same_as_method_name
11. Avoid_field_name_same_as_class_name
12. Use_proper_naming_convention_for_fields_in_interfaces
13. Use_proper_naming_convention_for_array_and_collection_type_fields
14. Use_proper_naming_convention_for_non_static_private_fields
15. Use_proper_naming_convention_for_methods
16. Use_proper_naming_convention_for_interfaces
17. Use_proper_naming_convention_for_local_variables
18. Use_proper_naming_convention_for_array_and_collection_type_local_variables
19. Avoid_using_short_variable_name
20. Avoid_using_short_field_name
21. Avoid_using_short_method_name
22. Avoid_using_long_variable_name
23. Avoid_using_long_field_name
24. Use_proper_naming_convention_for_packages
25. Use_proper_naming_convention_for_non_static_methods
26. Use_proper_naming_convention_for_non_final_static_fields
27. Use_proper_naming_convention_for_constant_fields
28. Use_proper_naming_convention_for_constant_private_fields
29. Use_proper_naming_convention_for_method_parameters
30. Use_proper_naming_convention_for_array_and_collection_type_method_parameters
31. Avoid_package_name_reserved_by_sun
32. Use_proper_naming_convention_for_classes
33. Use_proper_naming_convention_for_abstract_classes
34. Avoid_long_class_names
35. Use_proper_naming_convention_for_exceptions
36. Class_name_wrongly_ends_with_exception
37. Use_proper_naming_convention_for_static_methods
38. Use_proper_naming_convention_for_non_final_static_private_fields

Rule 1: Variable_names_in_uppercase_should_be_made_final

Severity:  Medium
Rule:  If a variable name is in uppercase, it is usually considered to be constant.
Reason:  If a variable name is in uppercase, it is usually considered to be constant.

Usage Example: 

public class Test
{
	public static int ABC = 10; // VIOLATION
	public final int DEF = 123; // VIOLATION
	
}

Should be written as:

public class Test
{
	public static final int ABC = 10; // CORRECTION
	public static final int DEF = 123; // CORRECTION
	
}

Reference:  No references available.

Rule 2: Avoid_naming_types_having_same_names_as_java_lang_types

Severity:  Low
Rule:  Since package java.lang is implicitly imported whenever a java file is created, declaring classes or interfaces with same name as java.lang types might bring confusions and ambiguities.
Reason:  Since package java.lang is implicitly imported whenever a java file is created, declaring classes or interfaces with same name as java.lang types might bring confusions and ambiguities.

Usage Example: 

public class Test 
{
 class Object {} //VIOLATION
}

Should be written as:

public class Test
{
 class MyObject {} //FIXED
}

Reference:  Not Available.

Rule 3: Use_proper_naming_convention_for_non_static_fields

Severity:  Medium
Rule:  Non-static fields should follow a standard naming convention.
Reason:  Non-static fields should follow a standard naming convention.

Usage Example: 

package com.rule;

public class Use_proper_naming_convention_for_non_static_fields_violation
{
	public int _value;
	String name; // VIOLATION if the naming convention is set to be "_.+"
}

Should be written as:

package com.rule;

public class Use_proper_naming_convention_for_non_static_fields_correction
{
	public int _value;
	String _name; // CORRECTION if the naming convention is set to be "_.+"
}

Reference:  http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html
http://www.beust.com/cedric/naming/

Rule 4: Avoid_local_variables_names_differing_only_in_case

Severity:  Medium
Rule:  Although this isn't an error, it makes it harder to read and confusing for the person reading viewing the source code.
Reason:  Although this isn't an error, it makes it harder to read and confusing for the person reading viewing the source code.

Usage Example: 

public class Test 
{
 public int sum(int foo)
{
  int Foo= 9; // VIOLATION
  return foo+5;
 }
}

Should be written as:

public class Test
{
 public int sum(int foo)
{
  int bar= 9; // FIXED
  return foo+5;
 }
}

Reference:  Allan Vermeulen, Scott W. Ambler, Greg Bumgardner, Eldon Metz, Trevor Misfeldt, Jim Shur, Patrick Thompson: "The Elements of Java Style" SIGS Cambridge, 2000, p. 18.

Rule 5: Avoid_method_parameter_names_differing_only_in_case

Severity:  Medium
Rule:  Although this isn't an error, it makes it harder to read and confusing for the person reading viewing the source code.
Reason:  Although this isn't an error, it makes it harder to read and confusing for the person reading viewing the source code.

Usage Example: 

public class Test 
{
 public int sum(int foo) // VIOLATION
{
  int Foo= 9;
  return foo+5;
 }
}

Should be written as:

public class Test
{
 public int sum(int bar)
{
  int Foo= 9;
  return bar+5;
 }
}

Reference:  Allan Vermeulen, Scott W. Ambler, Greg Bumgardner, Eldon Metz, Trevor Misfeldt, Jim Shur, Patrick Thompson: "The Elements of Java Style" SIGS Cambridge, 2000, p. 18.

Rule 6: Use_proper_naming_convention_for_tag_handlers_and_associated_classes

Severity:  Medium
Rule:  Using these naming conventions helps make it more clear the purpose of each class.
Reason:  Using these naming conventions helps make it more clear the purpose of each class.

Usage Example: 

import javax.servlet.jsp.tagext.TagExtraInfo;
import javax.servlet.jsp.tagext.TagLibraryValidator;
import javax.servlet.jsp.tagext.Tag;


public class THAC extends TagExtraInfo  // VIOLATION
{
 class THAC2 extends TagLibraryValidator // VIOLATION
 {
 }


 abstract interface THAC3 extends Tag  // VIOLATION
 {
 }
}

Should be written as:

import javax.servlet.jsp.tagext.TagExtraInfo;
import javax.servlet.jsp.tagext.TagLibraryValidator;
import javax.servlet.jsp.tagext.Tag;


public class THACFixed_TEI extends TagExtraInfo  // FIXED
{
 class THAC2Fixed_TLV extends TagLibraryValidator  // FIXED
 {
 }


 abstract interface THAC3Fixed_Tag extends Tag  // FIXED
 {
 }
}

Reference:  http://java.sun.com/developer/technicalArticles/javaserverpages/code_convention/

Rule 7: Use_proper_naming_convention_for_utility_classes

Severity:  Medium
Rule:  Using these naming conventions helps make it more clear the purpose of the class.
Reason:  Using these naming conventions helps make it more clear the purpose of the class.

Usage Example: 

public class Test// VIOLATION
{
 private UTIL() {} 
 public static long getSquare(int i) 
{
  return i* i;
 }

 public static long getCube(int i) 
{
  return i* i* i;
 }
}

Should be written as:

public class Test// FIXED
{
 private UTILUtil() {} 
 public static long getSquare(int i) 
{
  return i* i;
 }

 public static long getCube(int i) 
{
  return i* i* i;
 }
}

Reference:  Not Available.

Rule 8: Use_proper_naming_convention_for_getters

Severity:  Medium
Rule:  Prepend get to the names of getter methods.
Reason:  Prepend get to the names of getter methods.

Usage Example: 

public class MyClass
{
	 private int count = 10;

	 public int method () // VIOLATION
	{  
	  return count;
	 }

}

Should be written as:

public class MyClass
{
	 private int count = 10;

	 public int getCount () // CORRECTION
	{  
	  return count;
	 }

}

Reference:  http://www.ambysoft.com/javaCodingStandards.pdf

Rule 9: Use_proper_naming_convention_for_setters

Severity:  Medium
Rule:  Prepend set to the names of setter methods.
Reason:  Prepend set to the names of setter methods.

Usage Example: 

public class MyClass
{
	 private int count;

	 public int method (int count) // VIOLATION
	 {  
		this.count = count;
	 }

}

Should be written as:

public class MyClass
{
	 private int count;

	 public int setCount (int count) // CORRECTION
	 {  
		this.count = count;
	 }

}

Reference:  http://www.ambysoft.com/javaCodingStandards.pdf

Rule 10: Avoid_field_name_same_as_method_name

Severity:  Medium
Rule:  Avoid using field name same as method name.
Reason:  Avoid using field name same as method name.

Usage Example: 

package com.rule;

public class Avoid_field_name_same_as_method_name_violation
{
	int method;		// Violation.
	
	public void method()
	{
		// Some Code		
	}
		
}

Should be written as:

Reference:  Reference not available.

Rule 11: Avoid_field_name_same_as_class_name

Severity:  Medium
Rule:  Avoid field name same as class name.
Reason:  Avoid field name same as class name.

Usage Example: 

package com.rule;

public class Avoid_field_name_same_as_class_name_violation
{
	public int Avoid_field_name_same_as_class_name_violation;	//Violation.
	
	public void method()
	{
	
	}
		
}

Should be written as:

Reference:  Reference not available.

Rule 12: Use_proper_naming_convention_for_fields_in_interfaces

Severity:  Medium
Rule:  The fields defined in interfaces should follow a standard naming convention.
Reason:  The fields defined in interfaces should follow a standard naming convention.

Usage Example: 

package com.rule.Pack;

public interface Use_proper_naming_convention_for_fields_in_interfaces_violation
{
	int SomeConst = 100; // VIOLATION
}

Should be written as:

package com.rule.Pack;

public interface Use_proper_naming_convention_for_fields_in_interfaces_correction
{
	int SOME_CONST = 100; // CORRECTION
}

Reference:  No reference available.

Rule 13: Use_proper_naming_convention_for_array_and_collection_type_fields

Severity:  Medium
Rule:  Arrays and collections should have plural names to indicate that they are collections of objects (rather than single objects).
Reason:  Arrays and collections should have plural names to indicate that they are collections of objects (rather than single objects).

Usage Example: 

public class Test
{
	String[] arg; // VIOLATION
}

Should be written as:

public class Test
{
	String[] args; // FIXED
}

Reference:  Allan Vermeulen, Scott W. Ambler, Greg Bumgardner, Eldon Metz, Trevor Misfeldt, Jim Shur, Patrick Thompson: "The Elements of Java Style" SIGS Cambridge, 2000, pp. 26 - 27.

Rule 14: Use_proper_naming_convention_for_non_static_private_fields

Severity:  Medium
Rule:  Non-static fields should follow a standard naming convention.
Reason:  Non-static fields should follow a standard naming convention.

Usage Example: 

package com.rule;

public class Use_proper_naming_convention_for_non_static_private_fields_violation
{
	private int _value;
	private String name; // VIOLATION if the naming convention is set to be "_.+"
}

Should be written as:

package com.rule;

public class Use_proper_naming_convention_for_non_static_private_fields_correction
{
	private int _value;
	private String _name; // CORRECTION if the naming convention is set to be "_.+"
}

Reference:  http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html
http://www.beust.com/cedric/naming/

Rule 15: Use_proper_naming_convention_for_methods

Severity:  Medium
Rule:  Use proper names for boolean methods.
Reason:  Use proper names for boolean methods.

Usage Example: 

package com.rule;

public class Use_proper_naming_convention_for_methods_violation
{
	public void isValid() // VIOLATION
	{
	}
	
	public boolean getValue() // VIOLATION
	{
		return false;
	}
	
}

Should be written as:

package com.rule;

public class Use_proper_naming_convention_for_methods_correction
{
	public void validate() // CORRECTION
	{
	}
	
	public boolean isValueSet() // CORRECTION
	{
		return false;
	}
	
}

Reference:  No reference available.

Rule 16: Use_proper_naming_convention_for_interfaces

Severity:  Medium
Rule:  Interface names should follow standard naming conventions.
Reason:  Interface names should follow standard naming conventions.

Usage Example: 

package com.rule;

public interface Use_proper_naming_convention_for_interfaces_violation
{
	interface _Use_proper_naming_convention_for_interfaces_violation_INNER // VIOLATION
	{
	}
}
interface use_proper_naming_convention_for_interfaces_violation2 // VIOLATION
{
}

Should be written as:

package com.rule;

public interface Use_proper_naming_convention_for_interfaces_correction
{
	interface Use_proper_naming_convention_for_interfaces_correction_INNER // CORRECTION
	{
	}
}
interface Use_proper_naming_convention_for_interfaces_correction2 // CORRECTION
{
}

Reference:  http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html
http://www.unix.org.ua/orelly/java-ent/jnut/ch07_01.htm

Rule 17: Use_proper_naming_convention_for_local_variables

Severity:  Medium
Rule:  Local variables should follow a standard naming convention.
Reason:  Local variables should follow a standard naming convention.

Usage Example: 

package com.rule;

public class Use_proper_naming_convention_for_local_variables_violation
{
	public void method()
	{
		int localVar;
		String MY_STR; // VIOLATION if the naming convention is set to be "^[a-z].*"
	}
}

Should be written as:

package com.rule;

public class Use_proper_naming_convention_for_local_variables_correction
{
	public void method()
	{
		int localVar;
		String strMY_STR; // CORRECTION if the naming convention is set to be "^[a-z].*"
	}
}

Reference:  http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html http://www.unix.org.ua/orelly/java-ent/jnut/ch07_01.htm

Rule 18: Use_proper_naming_convention_for_array_and_collection_type_local_variables

Severity:  Medium
Rule:  Arrays and collections should have plural names to indicate that they are collections of objects (rather than single objects).
Reason:  Arrays and collections should have plural names to indicate that they are collections of objects (rather than single objects).

Usage Example: 

public class Test
{
 public void fubar()
 {
	 String[] arg; // VIOLATION
 }
}

Should be written as:

public class Test
{
	public void fubar()
 {
 	String[] args; // FIXED
 }
}

Reference:  Allan Vermeulen, Scott W. Ambler, Greg Bumgardner, Eldon Metz, Trevor Misfeldt, Jim Shur, Patrick Thompson: "The Elements of Java Style" SIGS Cambridge, 2000, pp. 26 - 27.

Rule 19: Avoid_using_short_variable_name

Severity:  Low
Rule:  Avoid using short variable name.
Reason:  Avoid using short variable name.

Usage Example: 

package com.rule;

public class Avoid_using_short_variable_name_violation
{
	public void method()
	{
		int i = 15;	// Violation
	}
		
}

Should be written as:

Rename the variable using a longer and informative name.

Reference:  Reference not available.

Rule 20: Avoid_using_short_field_name

Severity:  Low
Rule:  Avoid using short field name.
Reason:  Avoid using short field name.

Usage Example: 

public class Avoid_using_short_field_name_violation
{
	int i = 15;	// Violation
			
}

Should be written as:

Rename the field using a longer and informative name.

Reference:  Reference not available.

Rule 21: Avoid_using_short_method_name

Severity:  Low
Rule:  Avoid using short method name.
Reason:  Avoid using short method name.

Usage Example: 

package com.rule;

public class Avoid_using_short_method_name_violation
{
	public void me()		//Violation
	{
	
	}
		
}

Should be written as:

Reference:  Reference not available.

Rule 22: Avoid_using_long_variable_name

Severity:  Low
Rule:  Avoid using long variable name.
Reason:  Avoid using long variable name.

Usage Example: 

package com.rule;

public class Avoid_using_long_variable_name_violation
{
	public void method()
	{
		private int avoidUsingLongVariableName = 18;	// Violation
	}
		
}

Should be written as:

Reference:  Reference not available

Rule 23: Avoid_using_long_field_name

Severity:  Low
Rule:  Avoid using long field name.
Reason:  Avoid using long field name.

Usage Example: 

public class Avoid_using_long_field_name_violation
{
	private int avoidUsingLongfieldName = 18;	// Violation
		
}

Should be written as:

Reference:  Reference not available

Rule 24: Use_proper_naming_convention_for_packages

Severity:  Medium
Rule:  Class names should follow standard naming conventions.
Reason:  Class names should follow standard naming conventions.

Usage Example: 

package com.Rule; // VIOLATION

public class Use_proper_naming_convention_for_packages_violation
{
}

Should be written as:

package com.rule; // CORRECTION

public class Use_proper_naming_convention_for_packages_correction
{
}

Reference:  http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html
http://www.unix.org.ua/orelly/java-ent/jnut/ch07_01.htm

Rule 25: Use_proper_naming_convention_for_non_static_methods

Severity:  Medium
Rule:  Non-static methods should follow a standard naming convention.
Reason:  Non-static methods should follow a standard naming convention.

Usage Example: 

package com.rule;

public class Use_proper_naming_convention_for_non_static_methods_violation
{
	public void Method() // VIOLATION
	{
	}
}

Should be written as:

package com.rule;

public class Use_proper_naming_convention_for_non_static_methods_correction
{
	public void method() // CORRECTION
	{
	}
}

Reference:  http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html
http://www.unix.org.ua/orelly/java-ent/jnut/ch07_01.htm

Rule 26: Use_proper_naming_convention_for_non_final_static_fields

Severity:  Medium
Rule:  Non-final static fields should follow a standard naming convention.
Reason:  Non-final static fields should follow a standard naming convention.

Usage Example: 

package com.rule;

public class Use_proper_naming_convention_for_non_final_static_fields_violation
{
	public static int _value;
	static String name; // VIOLATION if the naming convention is set to be "_.+"
	static final long currID = 1000;
}

Should be written as:

package com.rule;

public class Use_proper_naming_convention_for_non_final_static_fields_correction
{
	public static int _value;
	static String _name; // COORECTION if the naming convention is set to be "_.+"
	static final long currID = 1000;
}

Reference:  http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html
http://www.beust.com/cedric/naming/

Rule 27: Use_proper_naming_convention_for_constant_fields

Severity:  Medium
Rule:  Constant fields should follow a standard naming convention.
Reason:  Constant fields should follow a standard naming convention.

Usage Example: 

package com.rule;

public class Use_proper_naming_convention_for_constant_fields_violation
{
	public static final int SomeConst = 100; // VIOLATION
}

Should be written as:

package com.rule;

public class Use_proper_naming_convention_for_constant_fields_correction
{
	public static final int SOME_CONST = 100; // CORRECTION
}

Reference:  http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html
http://www.unix.org.ua/orelly/java-ent/jnut/ch07_01.htm

Rule 28: Use_proper_naming_convention_for_constant_private_fields

Severity:  Medium
Rule:  Constant fields should follow a standard naming convention.
Reason:  Constant fields should follow a standard naming convention.

Usage Example: 

package com.rule;

public class Use_proper_naming_convention_for_constant_private_fields_violation
{
	public static final int SomeConst = 100; // VIOLATION
}

Should be written as:

package com.rule;

public class Use_proper_naming_convention_for_constant_private_fields_correction
{
	public static final int SOME_CONST = 100; // CORRECTION
}

Reference:  http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html
http://www.unix.org.ua/orelly/java-ent/jnut/ch07_01.htm

Rule 29: Use_proper_naming_convention_for_method_parameters

Severity:  Medium
Rule:  Method parameters should follow a standard naming convention.
Reason:  Method parameters should follow a standard naming convention.

Usage Example: 

package com.rule;

public class Use_proper_naming_convention_for_method_parameters_violation
{
	public void method(String MY_STR) // VIOLATION if the naming convention is set to be "^[a-z].*"
	{
	}
}

Should be written as:

package com.rule;

public class Use_proper_naming_convention_for_method_parameters_correction
{
	public void method(String my_str) // correction if the naming convention is set to be "^[a-z].*"
	{
	}
}

Reference:  http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html
http://www.unix.org.ua/orelly/java-ent/jnut/ch07_01.htm

Rule 30: Use_proper_naming_convention_for_array_and_collection_type_method_parameters

Severity:  Medium
Rule:  Arrays and collections should have plural names to indicate that they are collections of objects (rather than single objects).
Reason:  Arrays and collections should have plural names to indicate that they are collections of objects (rather than single objects).

Usage Example: 

public class Test
{
 public static void main(String[] arg) // VIOLATION
 {
 }
}

Should be written as:

public class Test
{
 public static void main(String[] args) // FIXED
 {
 }
}

Reference:  Allan Vermeulen, Scott W. Ambler, Greg Bumgardner, Eldon Metz, Trevor Misfeldt, Jim Shur, Patrick Thompson: "The Elements of Java Style" SIGS Cambridge, 2000, pp. 26 - 27.

Rule 31: Avoid_package_name_reserved_by_sun

Severity:  Medium
Rule:  Do not use package names that are reserved by Sun.
Reason:  Do not use package names that are reserved by Sun.

Usage Example: 

package javax.rule; // VIOLATION

public class Avoid_package_name_reserved_by_sun_violation
{

}

Should be written as:

package com.rule; // CORRECTION

public class Avoid_package_name_reserved_by_sun_correction
{

}

Reference:  No references available.

Rule 32: Use_proper_naming_convention_for_classes

Severity:  Medium
Rule:  Class names should follow standard naming conventions.
Reason:  Class names should follow standard naming conventions.

Usage Example: 

package com.rule;

public class Use_proper_naming_convention_for_classes_violation
{
	class _Use_proper_naming_convention_for_classes_violation_INNER // VIOLATION
	{
	}
}
class use_proper_naming_convention_for_classes_violation2 // VIOLATION
{
}

Should be written as:

package com.rule;

public class Use_proper_naming_convention_for_classes_correction
{
	class Use_proper_naming_convention_for_classes_correction_INNER // CORRECTION
	{
	}
}
class Use_proper_naming_convention_for_classes_correction2 // CORRECTION
{
}

Reference:  http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html
http://www.unix.org.ua/orelly/java-ent/jnut/ch07_01.htm
http://www.nbirn.net/Resources/Developers/Conventions/Style/Java_Naming.htm#ClassNames

Rule 33: Use_proper_naming_convention_for_abstract_classes

Severity:  Medium
Rule:  Abstract Class names should follow standard naming conventions.
Reason:  Abstract Class names should follow standard naming conventions.

Usage Example: 

package com.rule;

public class Use_proper_naming_convention_for_abstract_classes_violation	// Violation
{
	public abstract void method()
	{

	}
}

Should be written as:

Class name should be as per the pattern provided by parameter.

Reference:  Reference not available.

Rule 34: Avoid_long_class_names

Severity:  Medium
Rule:  Do not use long class names
Reason:  Do not use long class names

Usage Example: 

package com.rule;

public class Avoid_long_class_names_violation // VIOLATION
{

}

Should be written as:

package com.rule;

public class Use_short_names // CORRECTION
{

}

Reference:  No references available.

Rule 35: Use_proper_naming_convention_for_exceptions

Severity:  Medium
Rule:  Classes extending the Exception should follow standard naming conventions.
Reason:  Classes extending the Exception should follow standard naming conventions.

Usage Example: 

package com.rule;

public class Use_proper_naming_convention_for_exceptions_violation extends Exception // VIOLATION
{
}

Should be written as:

package com.rule;

public class Use_proper_naming_convention_for_exceptions_violationException extends Exception // CORRECTION
{
}

Reference:  http://www.nbirn.net/Resources/Developers/Conventions/Style/Java_Naming.htm#ExceptionName

Rule 36: Class_name_wrongly_ends_with_exception

Severity:  Medium
Rule:  This class is not derived from another exception, but ends with Exception which can lead to confusion.
Reason:  This class is not derived from another exception, but ends with Exception which can lead to confusion.

Usage Example: 

public class TestException // VIOLATION
{
	//...
}

Should be written as:

public class Test
{
	//...
}

Reference:  Not Available.

Rule 37: Use_proper_naming_convention_for_static_methods

Severity:  Medium
Rule:  Non-static methods should follow a standard naming convention.
Reason:  Non-static methods should follow a standard naming convention.

Usage Example: 

package com.rule;

public class Use_proper_naming_convention_for_static_methods_violation
{
	public static void Method() // VIOLATION
	{
	}
}

Should be written as:

package com.rule;

public class Use_proper_naming_convention_for_static_methods_correction
{
	public static void method() // CORRECTION
	{
	}
}

Reference:  http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html
http://www.unix.org.ua/orelly/java-ent/jnut/ch07_01.htm

Rule 38: Use_proper_naming_convention_for_non_final_static_private_fields

Severity:  Medium
Rule:  Non-final static fields should follow a standard naming convention.
Reason:  Non-final static fields should follow a standard naming convention.

Usage Example: 

package com.rule;

public class Use_proper_naming_convention_for_non_final_static_private_fields_violation
{
	private static int _value;
	private static String name; // VIOLATION if the naming convention is set to be "_.+"
	private static final long currID = 1000;
}

Should be written as:

package com.rule;

public class Use_proper_naming_convention_for_non_final_static_private_fields_correction
{
	private static int _value;
	private static String _name; // COORECTION if the naming convention is set to be "_.+"
	private static final long currID = 1000;
}

Reference:  http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html
http://www.beust.com/cedric/naming/