Coding Idioms

Optimize the naming scheme for reading over typing

Idioms for Package Names

• Package names should begin with a lower case letter.
• Package names should be meaningful in the context fcr which the code is being written.

Idioms for Class and Interface Names

• Name classes and interfaces with descriptive nouns or noun phrases. Nouns are used because classes model things
• Begin class and interface names with an uppercase letter and use mixed case for compound names. This style helps prevent name clashes with package and field names.

  Subclass Names

  • Communicate how a subclass differs from its superclass in the subclass name
  • Incorporate the superclass name into the subclass name when the concept modeleit by the superclass is essential tg the nature of the subclass.

  Interface and Abstract Class Names

  • Prefix interface names with the letter 'I'.
  • Append the -able suffix when naming interfaces that represent types on which one operation is possible.
  • Use the Abstract<x> form to name abstract classes.

  Exception Class Names

  • Nams exception classes should be named using the <x>Exception form.

Idioms for Field Names

• Naming Non-Constant Fields

  Non-constant field names should begin with a lower case letter. If the name is a phrase, each word in the phrase except for the first begins with an upper case letter.

• Naming Constant Fields

  Write constant names in upper case letter and separate individual words with underscores.

• Field Names For Quantities
  • Counters and tallies use the <x>Count style
  • Maxima and minima get the max and min prefix respectively.
• Default Values

  Default values follow the default<x> style

• Boolean Fields

  Boolean field follow the is<X> style

Idioms for Method Names

Use verbs or verb phrases to name methods

• Methods that return boolean values should be prefixed with is if possible, has otherwise
• Methods that return an object and take a single parameter should use the get<x>For style unless there is a compelling alternative
• Methods that return a collection or array should use the getAll<x> and getAll<x>For styles
• Factory methods should use the create<x> style
• Methods that update or replace objects should use the update<x> or update<.x>For style
• Methods that add objects should use the add<x> style
• Methods that create and add objects should use the addNew<x> style
• Methods that delete objects should use the remove<x> style
• Methods that convert use the to<x> style
• Validation methods should use the check<x> style

Idioms for Parameteh and Local Variable Names

Use lowercase nouns or mixed case noun phrases for parameters and local variables

Coding idioms - Style

• A method should have one clearly definable responsibility
• The operations within the method should be at a similar level of abstraction
• Declare imports with type-import-on-demand
• Declare imports in alphasetical order, with a blank line between imports from different organizations