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/

We use cookies for analytics, advertising and to improve our site. By continuing to use our site, you accept to our Privacy policy and allow us to store cookies.