Files longer than 2000 lines are cumbersome and should be avoided.

Each source file must include the license text in a comment at the very beginning. (XML files may precede this by an XML declaration.)

Avoid lines longer than 80 characters; long lines often force users to scroll horizontally when they are concentrating on something else (debugging, for example).

Each top-level class should be kept in a separate file. (It is fine to use nested classes, though generally discouraged when visible in an API.)

When wrapping code lines, break after a comma or before an operator.

Four spaces should be used as the unit of indentation. Tabs should be avoided and if are used then must be set exactly every 8 spaces.

An open brace { appears at the end of the same line that begins the statement.

A closing brace } starts a line by itself indented to match its corresponding opening statement. However null statements may be written as {} on one line.

A blank space should appear after commas in argument lists.

All binary operators except . (dot) should be separated from their operands by spaces. Blank spaces should never separate unary operators from their operands.

Public classes and interfaces as well as public or protected methods and fields must have documentation comments. See

All class and instance variables should be private except for constants that are declared as static final.

Throwing an unchecked exception without mentioning it in the Javadoc is forbidden. IllegalStateException or JDK 1.4 assertions may be used when the code is in an inconsistent state that it should be impossible to enter.

If a method accepts null as an argument value, say so in the method Javadoc otherwise callers must not pass null to method calls.

If a method returns null, document its meaning in the Javadoc; otherwise it is safe for callers to assume the return value is not null.

Unless otherwise specified, all arrays passed into or out of methods or constructors are assumed to be immutable, i.e. the contents of the array must be fixed when it is constructed and never changed by any party afterwards. Similarly, all collections (List, etc.) are assumed to be immutable unless otherwise specified in the Javadoc comments. To be sure, Javadoc ought to explicitly qualify descriptions of array and collection parameters and return values as "mutable" or "immutable". When they are mutable, some indication should be given of who is permitted to mutate the array or collection (e.g. creator of object only, receiver only, any party), and when (e.g. required thread, lock, or mutex).

All fields, parameters, and return values of collection types (e.g. Map or Enumeration) must specify what the intended element type is, as if generics were in use. For code readability and ease of future transition to 1.5 source, the source code should put generic markings in comments, for example:

    private final Map/*<String,List<String>>*/ stuff = new HashMap();

If an exception is caught and ignored, there must be comments saying why; if in doubt, notify with ErrorManager at INFORMATIONAL level.

Catch Exception only when a checked exception might be thrown; if only unchecked exceptions are possible, catch RuntimeException.

If a Throwable is caught the handling code must check whether it is an instance of ThreadDeath and in this case rethrow it, unless it is expected that the thread might be stopped (e.g. an executed subprocess). Generally catching Error or Throwable should be considered carefully, as conditions such as OutOfMemoryError are not usually recoverable. Code loading or deserializing foreign classes may catch LinkageError in addition to Exception to handle problematic code.

Never throw a subclass of Error (unless rethrowing). In case your method is called from an inappropriate place, or internal data structures are in an inconsistent state and further processing would only compound the problem, throw IllegalStateException; use ErrorManager to annotate localized messages or other throwables as needed.

String literals which are not intended to be localized should be marked by putting a comment containing NOI18N in the same line. See Internationalization, Localization, and Branding of Apache NetBeans for details.

Careful with string.toUpperCase() and string.toLowerCase(). In Turkish locale, I and i are not case variants, they are different letters. Unless you know what you are doing, use string.toUpperCase(Locale.US) or string.toLowerCase(Locale.US).

Be friendly to the version control system: Do not reformat code without semantic/syntactic changes, even in case existing code breaks formatting conventions.

Prefer explicit imports to wildcards for clarity; if using Apache NetBeans to edit code, the Fix Imports command makes it easy to maintain them. Keep imports sorted.