• Post Reply Bookmark Topic Watch Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This page was migrated from a javaranch.com.jsp

Introduction

The Java language gives you all the room you need to write code that would be very
difficult for others to understand. Java also permits you to write code that is very easy
to understand. Most development teams would prefer the latter.



A style guide provides provides a map so that the code generated by a group of programmers
will be consistent and, therefore, easier to read and maintain. Many people do not care for the
style guide offered by Sun.
This document is one alternative.



This document covers most areas where there could be confusion or difference of opinion.
Areas that have never been a problem in our experience are undocumented, but we do provide
at least one example to demonstrate proper use somewhere in the document.



1 - Formatting

    1.1 - Indentation

    All indents are four spaces. All indenting is done with spaces, not tabs.
    (examples and reasoning)


    Matching braces are always in the same column as their construct.
    (examples)


    All if, while and for statements must use braces even if they control just
    one statement. (reasoning)


    1.2 - Spacing and Blank Lines

    All identifiers are surrounded with whitespace.
    (examples and reasoning)


    There are a few exceptions to this rule:
    (examples and reasoning)


       All method names should be immediately followed by a left parenthesis.

       All array dereferences should be immediately followed by a left square bracket.

       The unary operator should be immediately preceded or followed by the operand.

       The cast should be written with no spaces.



    Use the occasional blank line within methods to break up related chunks of code.
    Use one or two blank lines between all methods.


    1.3 - Class Member Ordering



    Keep private methods above the methods that use them and below the constructors
    (even if the constructors use them).



    1.4 - Maximum Line Length

    Avoid making lines longer than 120 characters. If your code starts to get indented way to
    the right, consider breaking your code into more methods.
    (reasoning)

    1.5 - Parentheses

    Parentheses should be used in expressions not only to specify order of precedence,
    but also to help simplify the expression. When in doubt, parenthesize.




2 - Identifiers

All identifiers use letters ('A' through 'Z' and 'a' through 'z') and numbers
('0' through '9') only. No underscores, dollar signs or non-ascii characters.



Hungarian Notation violates OO abstraction and is not to be used.
(reasoning)




    2.1 - Classes and Interfaces

    All class and interface identifiers will use mixed case. The first letter of
    each word in the name will be uppercase, including the first letter of the name.
    All other letters will be in lowercase, except in the case of an acronym,
    which will be all upper case.
    (examples)

    2.2 - Packages

    Package names will use lower case characters only. Try to keep the length under
    eight (8) characters. Multi-word package names should be avoided.
    (examples)

    2.3 - All Other Identifiers

    All other identifiers, including (but not limited to) attributes, variables, methods
    and parameters will use this default naming convention. This includes
    <strong>final</strong> identifiers.


    The first letter of each word in the name will be uppercase, except for the
    first letter of the name.


    All other letters will be in lowercase, except in the case of an embedded
    acronym, which will be all uppercase. Leading acronyms are all lower case.
    (examples and reasoning)


3 - Coding


    3.1 - Constructs to Avoid

    Never use do..while.
    examples and reasoning


    Never use "return" in the middle of a method.
    (reasoning)


    Never use "continue".
    (reasoning)


    Never use "break" other than in a switch statement.
    (reasoning)

    3.2 - Do Not Compound Increment or Decrement Operators

    Use an extra line for the increment or decrement.
    (examples and reasoning)

    3.3 - Initialization

    Try to always initialize all variables when they are declared.
    (examples and reasoning)

    3.4 - Scope

    All class attributes must always be private, except for inner classes and some final values.


4 - Self-Documenting Code




     

         

             
           

       



Rather than trying to document how you perform a complex algorithm, try to
make the algorithm easier to read by introducing more identifiers. This helps
in the future if the algorithm changes and the documentation does not.
(examples and reasoning)

    Bookmark Topic Watch Topic
  • New Topic