Code Style. Java

Use this page to configure formatting options for Java files. When you change these settings, the Preview pane shows how this will affect your code.

Tabs and Indents

Use tab character

Use the Tab key for indentation. When the checkbox is cleared, IntelliJ IDEA uses spaces instead of tabs.

• If this checkbox is selected, the indentation for nested code blocks will use tabs and spaces as needed, while alignment indentation will use only spaces.
• If this checkbox is cleared, only tabs are used. This means that a group of spaces that fits the specified tab size is automatically replaced with a tab, which may result in breaking fine alignment.

The Smart tabs checkbox is available if the Use tab character option is enabled.

In this field, specify the number of spaces included in a tab.

In this field, specify the number of spaces to be inserted for each indent level.

Specify the indentation for lines that continue from the previous line, making it clear that they are part of the same statement or block of code. Continuation indents are used when a single statement is too long to fit on one line.

Keep indents on empty lines

If this checkbox is selected, IntelliJ IDEA will keep indents on the empty lines as if they contained some code.

If this checkbox is cleared, IntelliJ IDEA will delete the tab characters and spaces.

In this field, specify the number of spaces to be inserted at the next line before a label statement.

Absolute label indent

If this checkbox is selected, label indentation is counted as an absolute number of spaces. Otherwise, label indentation is counted relative to previous indent levels.

Do not indent top level class members

Select this checkbox to have top level class members located at the class declaration indentation level.

Use indents relative to expression start

Use this checkbox to switch between the two possible indentation behaviors:

• If this option is disabled, code blocks will be aligned with the nearest ancestor block that begins on a new line.
• If the option is enabled, the blocks of code will be formatted in columns.

Spaces

Use this tab to specify where you want spaces in your code. To have IntelliJ IDEA automatically insert a space at a location, select the checkbox next to this location in the list. The results are displayed in the preview pane.

Wrapping and Braces

In this tab, customize the code style options, which IntelliJ IDEA will apply on reformatting the source code. The left-hand pane contains the list of exceptions ( Keep when reformatting ), and placement and alignment options for the various code constructs (lists, statements, operations, annotations, and so on) The right-hand pane shows the preview.

Alignment takes precedence over indentation options.

Hard wrap at

Use the Hard wrap at field to specify a margin space required on the right side of an element. If you select the Default option, then a value of the right margin from the global settings is used.

Wrap on typing

Use the Wrap on typing settings to specify how the edited text is fitted in the specified Hard wrap at :

• Default : in this case IntelliJ IDEA uses the Wrap on typing option that is specified in the global settings.
• Yes : in this case IntelliJ IDEA uses the value specified in the Right Margin field.
• No : in this case this option is switched off and a line can exceed the value specified in the right margin.

Visual guides

Use the Visual guides field to specify multiple right margins. You can leave a default value or enter the number of spaces for your margin. If you want to specify several margins, enter numbers separated by comma.

Keep when reformatting

Use the checkboxes to configure exceptions that IntelliJ IDEA will make when reformatting the source code. For example, by default, the Line breaks checkbox is selected. If your code contains lines that are shorter than a standard convention, you can convert them by disabling the Line breaks checkbox before you reformat the source code.

Wrapping options

The wrapping style applies to the various code constructs, specified in the left-hand pane (for example, method call arguments, method declaration parameters, or assignment statements).

From this list, select the desired wrapping style:

• Do not wrap : when this option is selected, no special wrapping style is applied. With this option selected, the nested alignment and braces settings are ignored.
• Wrap if long : select this option to have lines going beyond the right margin wrapped with proper indentation.
• Wrap always : select this option to have all elements in lists wrapped, so that there is one element per line with proper indentation.
• Chop down if long : select this option to have elements in lists that go beyond the right margin wrapped, so that there is one element per line with proper indentation.

Alignment options

Align when multiline

If this checkbox is selected, a code construct starts at the same column on each next line. Otherwise, the position of a code construct is determined by the current indentation level.

Select this checkbox to have the specified character or characters moved to the next line when the lines are wrapped.

'else' on new line

Use this checkbox to have the corresponding statements or characters moved to the next line.

Select this checkbox to have the code after the specified character moved to a new line.

Special 'else if' treatment

If this checkbox is selected, else if statements are located in the same line.

Otherwise, else if statements are moved to the next line to the corresponding indent level.

Indent 'case' branches

If this checkbox is selected, the case statement is located at the corresponding indent level. Otherwise, case statement is placed at the same indent level with switch .

Braces placement options

Braces placement style

Use this list to specify the position of the opening brace in class declarations , method declarations, and other types of declarations. The available options are:

• End of line : select this option to have the opening brace placed at the declaration line end.
• Next line if wrapped : select this option to have the opening brace placed at the beginning of the line after the multiline declaration line.
• Next line : select this option to have the opening brace placed at the beginning of the line after the declaration line.
• Next line shifted : select this option to have the opening brace placed at the line after the declaration line being shifted to the corresponding indent level.
• Next line, each shifted : select this option to have the opening brace placed at the line after the declaration line being shifted to the corresponding indent level, and have the next line shifted to the next indent level as well.

From this list, choose the braces introduction method for if , for , while , and do () while statements. The available options are:

• Do not force : select this option to suppress introducing braces automatically.
• When multiline : select this option to have braces introduced automatically if a statement occupies more than one line. Note that IntelliJ IDEA analyzes the number of lines in the entire statement but not only its condition. IntelliJ IDEA will insert braces automatically:
• Always : select this checkbox to have braces always introduced automatically.

Chained method calls

Use the following options to format chained method calls and make them easier to read. Note that builder method calls are always wrapped regardless of the settings for chained calls.

Wrap first call

Allow wrapping the first method call in chained methods.

Align when multiline

Align several method calls.

Specify comma-separated names (identifiers) of methods that you want to be treated as builder methods.

For example: withTitle,withYear,addAuthor,withName,withLastName,end,build

Keep builder methods indents

Keep additional indents that you insert manually intact as you reformat code.

Blank lines

Use this tab to define where and how many blank lines you want IntelliJ IDEA to retain and insert in your code after reformatting. For each type of location, specify the number of blank lines to be inserted. The results are displayed in the preview pane.

Keep maximum blank lines

In this area, specify the number of blank lines to be kept after reformatting in the specified locations.

Minimum blank lines

In this area, specify the number of blank lines to be present in the specified locations.

These settings do not influence the number of blank lines before the first and after the last item.

JavaDoc

Define the way Javadoc comments should be aligned.

• Align parameter descriptions : align parameter descriptions against the longest parameter name. Otherwise, the description is separated from the corresponding parameter name by a single space.
• Align thrown exception descriptions : align thrown exception descriptions against the longest exception name. Otherwise, the description is separated from the exception name by a single space.

Define where blank lines should be inserted in Javadoc comments.

• After description : automatically insert a blank line after the description section of a Javadoc comment.
• After parameter descriptions : automatically insert a blank line after the group of @param tags.
• After return tag :automatically insert a blank line after the @return tag.

In this area, define whether invalid tags should be preserved or not.

• Keep invalid tags : preserve the @invalidTag .
• Keep empty @param tags : preserve the @param tags without the description.
• Keep empty @return tags : preserve the @return tags without the description.
• Keep empty @throws tags : preserve the @throws tags without the description.

In this area, specify additional formatting options for Javadoc comments.

• Enable leading asterisks : start each line of a Javadoc comment with an asterisk.
• Use @throws rather than @exception : use the @throws tag.
• Wrap at right margin : wrap the text that exceeds the right margin to the next line.
• Generate "

  " on empty lines : automatically insert the

  tag on an empty line.
• Keep empty lines : select this checkbox to have manually added empty lines preserved.
• Do not wrap one line comments : keep short comments on one line with the opening and closing tags.
• Preserve line feeds : if this checkbox is not selected (by default), line feeds are not preserved on reformatting. This is convenient when comments should be formatted within the boundaries of a paragraph, to occupy minimum space. If this checkbox is selected, line feeds will be preserved.
• Parameter descriptions on new line : place the description of a Javadoc parameter (if any) to a new line. It uses the indent based on the continuation indent value.
• Indent continuation lines : indent subsequent lines in multiline comments.

Arrangement

This tab lets you define a set of rules that rearranges your code according to your preferences.

Code arrangement is not a part of code reformatting. To rearrange your code, run the dedicated action or configure the IDE to automatically rearrange code on save.

Use this area to set the grouping rules.

• Keep getters and setters together Select this checkbox to keep getter and setter methods together. By default, this checkbox is selected.
• Keep overridden methods together Select this checkbox to group the overridden methods together by class and interface. In order list, select keep order or order by name options.
• Keep dependent methods together Select this checkbox to group the dependent methods together. In the order list, select depth-first order or breadth-first order options. The former will arrange the methods according to the nesting hierarchy; the latter will group together the sibling methods from the same nesting level.

class foo < public function parent() < $this->child1(); $this->child2(); > private function child1() < $this->nested1(); > private function nested1() < $this->nested2(); > private function nested2() < >private function child2() < >>

class foo < public function parent() < $this->child1(); $this->child2(); > private function child1() < $this->nested1(); > private function child2() < >private function nested1() < $this->nested2(); > private function nested2() < >>

Use this area to define elements order as a list of rules, where every rule has a set of matches such as modifier or type.

• : use this button to add a rule. The empty rule area opens.
• : use this button to add a section rule. The section rule lets you move methods or variables into sections that you have defined. For example, you can create the following section rule: After the arrangement, methods in the class will be rearranged as specified in the created section rule and will be surrounded by comments:

Use this area to create a new matching rule or edit an existing one. You can select from the following filters:

• Type : use this filter to choose classes or methods for your rule. Note that clicking a type keyword twice negates the condition.
• Modifier : use this filter to select the types of modifiers for the rule. Note that clicking a modifier keyword twice negates the condition.
• Name : use this field to specify entry names in the rule. This filter matches only entry names, such as field names, method names, class names, and so on. The filter supports regular expressions and uses a standard syntax. The match is performed against the entire name.
• Order : use this list to select the sorting order for the rule. This option is useful when more than one element uses the same matching rule. In this case, selecting Keep order will keep the same order as was set before the rearrangement and selecting Order by Name will sort the elements with the same matching rule by their names.
• Aliases : this option displays aliases that were defined in the Rules Alias Definition dialog. You can remove the ones you do not need.

This icon appears when you select Order by Name from the Order list. The icon indicates that the items in this rule are sorted alphabetically.

Imports

This table lists actions to be performed when imports are optimized.

In this area, configure general import options.

• Use single class import : import only a particular class from a package during code generation or import optimization. Otherwise, a statement that imports an entire package is inserted.
• Use fully qualified class names : use the fully qualified name of the class to be imported during code generation or import optimization. Otherwise, a normal import statement is inserted.
• Insert imports for inner classes : create imports for the inner classes referenced in your code.
• Use fully qualified names in JavaDoc : use fully qualified class names in Javadocs. Otherwise, a class is imported.
• Class count to use import with '*' : specify the number of classes to be imported from a single package until all statements that import a single class are substituted with a statement that imports an entire package.
• Names count to use static import with '*' : in this field, specify the number of members to be imported from a single class until all statements that import a single member are substituted with a statement that imports an entire class.

JSP Imports Layout

In this area, configure how JSP import statements should be organized in your code. The introduced changes are displayed in the Preview pane below.

• Prefer comma separated import list : select this option to import statements organized in a comma separated list.
• Prefer one import statement per page directive : select this option to have one import statement created per line.

Packages to Use Import with '*'

In this area, configure a list of packages and classes to be always imported completely.

• Static : select this checkbox, if you want to declare static import for the selected class.
• Package : in the text fields of this column, specify the packages and classes to be always imported completely. Note that IntelliJ IDEA automatically adds .* at the end of the package name once you finish typing.
• With Subpackages : select this checkbox to have all the subpackages of the selected package imported completely.
• Add Package : click this button to add a new entry to the list of packages and classes.
• Add Blank : click this button to add an empty separator to the list of packages and classes.
• Remove : click this button to delete the selected package or class from the list.

In this area, configure how import statements should be organized in your code. You can set up certain classes to be positioned first, or last, or one after another. Imported classes will be grouped as per their packages and sorted alphabetically within a package.

• Layout static imports separately : if this checkbox is selected, all static imports will be kept in a separate section. Otherwise, all import statements will be sorted according to the specified layout rules.
• Static : select this checkbox, if you want to declare static import for the selected package.
• Package : in the text fields of this column, specify the packages to be imported.
• With Subpackages : select this checkbox to have IntelliJ IDEA apply the layout rules to all the subpackages of the selected package.
• Add Package : click this button to add a new entry to the list of packages.
• Add Blank : click this button to have a blank line inserted after the selected entry, which indicates that a blank line should be inserted between the corresponding import statements.
• Move Up / Move Down : click these buttons to move a package or a blank line up or down in the list thus defining the order of import statements.
• Remove : click this button to delete the selected package from the list.

Code Generation

• Prefer longer names : Highlight the longest name in the lookup list for code completion. If disabled, highlight the shortest name.
• Name prefix and Name suffix : Specify the prefixes and suffixes for generating suggestions for naming new symbols using the IntelliJ IDEA code generation features. For blank fields, the default name suggestions without prefixes or suffixes are used. When you add a prefix value, IntelliJ IDEA automatically converts the first letter of the suggested base name to the upper case. For example, if the prefix for a static field is defined as s and the type of the field is Counter , then the suggested static field name will be sCounter . This prefix does not affect the generation of the getter and setter method names. So, in this case, the accessor names will be getCounter and setCounter .

Select the default access level for generated fields and methods.

You can either specify it explicitly, or select Escalate to automatically raise it to a necessary level.

Specify whether you want to generate local variables and parameters with the final modifier by default.

Use this area to configure code style for generated comments (line Ctrl+/ and block Ctrl+Shift+/ ):

• Line comment at first column : start line comments ( Ctrl+/ ) at the first column. If you disable the option, the comments will be aligned with your code.
• Add a space at comment start : insert a space between the line comment character and the first character of the commented line.
• Enforce on reformat : insert a space between a line comment character and the first character of a commented line in existing comments when you're reformatting your code. Note that the first character has to be an alphanumeric symbol, otherwise the space won't be inserted. For example, the //&Lorem ipsum comment will be ignored by the reformatter. This option becomes available when Add a space at comment start is enabled.
• Block comment at first column : start block comments ( Ctrl+Shift+/ ) at the first column. If you disable the option, the comments will be aligned with your code.
• Add spaces around block comments : insert a space between the block comment character and the first character of the commented text.

Override Method Signature

• Insert @Override annotation : Insert @Override annotations when you override a method.
• Repeat synchronized modifier : Add the synchronized keyword when you override a method that is synchronized.
• Annotations to Copy : Specify which annotations should be copied over to the method that you override.
• Use external annotations : Prompt to specify whether you want an annotation to be stored in the source code or externally. If disabled, annotations will be added to the source code by default.

If a lambda expression calls an existing method, it is preferable to refer to the method by name using a method reference. These checkboxes affect the Lambda can be replaced with method reference inspection. If enabled, the corresponding lambda expressions will be highlighted as warnings with a relevant quick-fix. If disabled, the code will not be highlighted, but an intention to replace the lambda expression with a method reference will still be available.

• Use Class::isInstance and Class::cast when possible For example, replace obj1 -> obj1 instanceof Foo with Foo.class::isInstance and obj -> (Foo)obj with Foo.class::cast .
• Replace null-check with Objects::nonNull or Objects::isNull For example, replace x -> x != null with Objects::nonNull .
• Use Integer::sum, etc. when possible For example, replace (a, b) -> a + b with Integer::sum .