Naming Conventions and Practices

Java naming conventions/good practices

• is prefix should be used for boolean variables and methods. few alternatives: has, can and should
  
• The term compute can be used in methods where something is computed.
  
  • valueSet.computeAverage(); matrix.computeInverse()
    
• The term find can be used in methods where something is looked up.
  
  • vertex.findNearestVertex(); matrix.findSmallestElement();
    
• The term initialize can be used where an object or a concept is established.
  
  • printer.initializeFontSet();
    
• Plural form should be used on names representing a collection of objects.
  
  • Collection<Point> points;
    
• Some key verbs
  
  • get/set, add/remove, create/destroy, start/stop, insert/delete, increment/decrement, old/new, begin/end
    
  • first/last, up/down, min/max, next/previous, old/new, open/close, show/hide, suspend/resume, etc.
    
• Abbreviations in names should be avoided.
  
  • computeAverage(); // NOT: compAvg();
    
    
  • ActionEvent event; // NOT: ActionEvent e;
    
  • catch (Exception exception) { // NOT: catch (Exception e) {
    
• Negated boolean variable names must be avoided.
  
  • bool isError; // NOT: isNoError
    
    
  • bool isFound; // NOT: isNotFound
    
• Associated constants (final variables) should be prefixed by a common type name.
  
  • final int COLOR_RED = 1;
    
  • final int COLOR_GREEN = 2;
    
  • final int COLOR_BLUE = 3;
    
• Exception classes should be suffixed with Exception.
  
  • class AccessException extends Exception.
    
• Default interface implementations can be prefixed by Default.
  
  • class DefaultTableCellRenderer implements TableCellRenderer
    
• Singleton classes should return their sole instance through method getInstance
  
• File content must be kept within 80 columns.
  
• Imported classes should always be listed explicitly.
  
  • import java.util.List; // NOT: import java.util.*;
    
• . Class and Interface declarations should be organized in the following manner:
  
  • Class/Interface documentation.
    
  • class or interface statement.
    
  • Class (static) variables in the order public, protected, package (no access modifier), private.
    
  • Instance variables in the order public, protected, package (no access modifier), private.
    
  • Constructors.
    
  • Methods (no specific order).
    
• Method modifiers should be given in the following order:
  
  • <access> static abstract synchronized <unusual> final native. The <access> modifier (if present) must be the first modifier.
    
• Type conversions must always be done explicitly. Never rely on implicit type conversion.
  
  • floatValue = (int) intValue; // NOT: floatValue = intValue;
    
• Array specifiers must be attached to the type not the variable.
  
  • int[] a = new int[20]; // NOT: int a[] = new int[20]
    
• Class variables should never be declared public.
  
• Variables should be kept alive for as short a time as possible.
  
• Loop variables should be initialized immediately before the loop.
  
  • isDone = false; while (!isDone) {
    
• The use of do-while loops can be avoided.
  
• The use of break and continue in loops should be avoided.
  
  • These statements should only be used if they prove to give higher readability than their structured counterparts.
    
• Reference: http://geosoft.no/development/javastyle.html