Controls when and how lines are wrapped.
Lets you control the general line wrapping options.
Wrap lines
Enables or disables automatic line wrapping. When enabled, Jalopy tries to keep lines within the maximal line length and breaks statements across lines when necessary.
Disabling line wrapping does not mean that existing line breaks are kept, but rather that no effort is taken to keep lines in between the maximal line length upon reformatting
Line length
Lets you specify the maximal line length. Jalopy tries (more or less—depending on the used indentation scheme) to limit each line within the given length.
Lets you define the wrapping policy for operators. Line wrapping will often occur with statements that consist of several (possibly long) expressions. Here you specify whether line wrapping should occur before or after the expression operator.
Wrap before operators
When enabled, line breaks will be inserted before operators.
Example 2.109. Wrap before operators (Standard indented)
if ((condition1 && condition2)
|| (condition3 && condition4)
|| !(condition5 && condition6)) {
doSomethingAboutIt();
}
Wrap after operators
When enabled, line breaks will be inserted after operators.
Example 2.110. Wrap after operators (Standard indented)
if ((condition1 && condition2) ||
(condition3 && condition4) ||
!(condition5 && condition6)) {
doSomethingAboutIt();
}
Please note that wrapping for the comma and dot operator is currently always performed after the operators! If you happen to use Sun Brace styling, you might want to enable continuation indentation for blocks to let the statement body stand out. See “Block continuation indentation” for more information.
Lets you specify for which code elements line breaks should be kept.
Declaration parameters
When enabled, existing line breaks after the commas of declaration parameters are kept. Otherwise line wrapping is performed according to the current settings.
Since 1.6
Example 2.111. Nicely laid out method declaration
void test( String rName, boolean rPendandic ) { ... }
After formatting this code could look like this (because everything fits in one line):
But with the "Keep line breaks" option enabled, it may look like this:
Example 2.113. Method declaration after formatting with kept line breaks (Endline indented)
void test( String rName, boolean rPendandic ) { ... }
Alternatively, you might want to use the
//J:KEEP+
pragma comment
to keep line breaks on a case by case basis.
Call arguments
When enabled, existing line breaks after the commas of call arguments are kept. Otherwise line wrapping is performed according to the current settings.
Since 1.6
After formatting this code could look like this (because everything fits in one line):
But with the "Keep line breaks" option enabled, it may look like this:
Example 2.116. Method call after formatting with kept line breaks (Endline indented)
obj.method1( test, test2, test3 );
Alternatively, you might want to use the
//J:KEEP+
pragma comment
to keep line breaks on a case by case basis.
Operators
When enabled, existing line breaks before or after infix operators and the comma operator of method declaration parameters or method call arguments are kept. Otherwise line wrapping is performed according to the current settings.
Since 1.0
Example 2.117. Operators with forced line breaks
if ((condition1 && condition2)
|| (condition3 && condition4)
|| !(condition5 && condition6))
{
...
}
After formatting this code could look like this (because not everything fits in one line and not line breaks are forced):
Example 2.118. Operators after formatting (wrapping is done on-demand)
if ((condition1 && condition2) || (condition3 && condition4) ||
!(condition5 && condition6))
{
...
}
But with the "Keep line breaks" option enabled, it may look like this:
Example 2.119. Operators after formatting with kept line breaks
if ((condition1 && condition2) ||
(condition3 && condition4) ||
!(condition5 && condition6))
{
...
}
Please note that it does not matter what wrapping policy for operators you choose. Jalopy will keep line breaks even if the operators move!
String concats
When enabled, existing line breaks before or after the plus operator of concatenated string literals are kept. Otherwise line wrapping is performed according to the current settings.
Since 1.0.1
Example 2.120. Nicely laid out string constant
query = "select a.prop_text, " + " a.contest_title, " + " from contest a " + " where a.language_code = b.language_code " + " and b.bob = c.bob " + " and a.x = ? " + " order by a.bob, " + " c.language";
After formatting this code could look like this:
Example 2.121. String constant after formatting
query = "select a.prop_text, " + " a.contest_title, " + " from contest a " + " where a.language_code = b.language_code " + " and b.bob = c.bob " + " and a.x = ? " + " order by a.bob, " + " c.language";
But with the "Keep string concats" option enabled, it may look like this:
Example 2.122. String constant after formatting with "Keep line breaks" (Standard indented)
query = "select a.prop_text, " + " a.contest_title, " + " from contest a " + " where a.language_code = b.language_code " + " and b.bob = c.bob " + " and a.x = ? " + " order by a.bob, " + " c.language";
Please note that it does not matter what wrapping policy for operators you choose. Jalopy will keep line breaks even if the operators move!
Array elements
When enabled, existing line breaks after the separator comma between individual array elements are kept. Otherwise line wrapping is performed according to the current settings if there can be no pragma comment found that indicates otherwise.
Since 1.5
Example 2.123. Array declarations
String[] foo = new String[] { "foo", }; String[] bar = new String[] { "bar", "car", };
Example 2.124. Array declarations after reformat
String[] foo = new String[] { "foo", }; String[] bar = new String[] { "bar", "car", };
Example 2.125. Array declarations after reformat with "Keep line breaks"
String[] foo = new String[] { "foo", }; String[] bar = new String[] { "bar", "car", };
Example 2.126. Array declarations with pragma comment to keep line breaks
String[] foo = new String[] { "foo", }; String[] bar = new String[] { //J:KEEP "bar", "car", };
Alternatively, you might want to use the
//J:KEEP+
pragma comment
to keep line breaks on a case by case basis.
Strictly obey "Keep line breaks"
When using endline indentation, line breaks may not always be kept because doing so would break the endline indent contract and lead to inconsistent indentation behavior. Enabling this option will cause Jalopy to keep existing line breaks even in such cases. Please note that this option is only available when endline indentation is enabled and any of the "Keep line breaks" options selected!
Since 1.8
When the option is disabled, Jalopy won’t keep the line break before the first call argument because it goes against the endline indentation rules.
Example 2.128. Method call - endline indented
String firstSymbol = eraseNonBreakingSpaceFromSymbol(symbol1, symbol2);
But if you really favor keeping the line break, enabling the option would yield:
Example 2.129. Method call - line break kept
String firstSymbol = eraseNonBreakingSpaceFromSymbol( symbol1, symbol2);
Treat two string literals as string concatenation
This option lets you control what is considered a string concatenation. By default, Jalopy treats the plus (+) operator as a string concatenation when either one of the operands is a string literal. But you might want to narrow this behavior to only treat two string literals as a string concatenation. Please note that this option is only available when any of the "Keep line breaks" options is selected!
Since 1.8
Example 2.130. String concatenations
String query = "select a.prop_text, " + " a.contest_title, " + " from contest a " + " where a.language_code = b.language_code "; String name = "Walther" + getNick();
When this option is disabled, all operators in the example above are considered string concatenations and therefore line breaks are kept.
Example 2.131. String concatenations
String query = "select a.prop_text, " + " a.contest_title, " + " from contest a " + " where a.language_code = b.language_code "; String name = "Walther" + getNick();
When enabled, only those plus operators with two string literals on either side would retain any line breaks like in the example above.
Disable wrapping for complex expressions
For complex expressions a common technique to enhance readability is to break the expression into several sub-expressions that can be stored in temporary variables that are placed on different lines.
Example 2.132. Complex expression
if (conditionOne && | ("foo".equals(aStr) || "bar".equals(aStr)) | doSomething(); |
Example 2.133. Refactored expression
boolean conditionTwo = "foo".equals(aStr); | boolean conditionThree = "bar".equals(aStr); | | if (conditionOne && | (conditionTwo || conditionThree)) | doSomething(); |
In order to determine occurrences of complex expressions, enabling this option will cause automatic line wrapping to be disabled when a complex expression gets printed. A warning message will be logged in the Printer category that informs you about the location of the expression.
Since 1.5
Example 2.134. Flagged complex expression
|
if (conditionOne && (conditionTwo || conditionThree))
doSomething(); |
Avoid bare left parenthesis
With Endline indentation and "Wrap on-demand after left parenthesis" or "Keep line break for operators" enabled, line breaks after left parentheses may look ugly. If this option is enabled, such line breaks are avoided. This option was mainly introduced to fix some unwanted behavior of earlier releases without breaking compatibility. It is recommended to have it enabled.
Since 1.4
Example 2.135. Bare left parenthesis
this.customerNumber = new CustomerNumber( ServiceManager.createService());
Example 2.136. Avoided bare left parenthesis
this.customerNumber = new CustomerNumber(ServiceManager.createService());
Prefer within call after assignment
This option lets you define where a line wrap should preferably occur for call statements after assignments that don’t fit into the maximal line length. The option is only meant to let you adjust behavior when “Prefer wrap after assignments” has been enabled. Please see explanation there.
Since 1.7
Example 2.137. Wrapping assignment expression
nuMBeans = NuvegaPropertiesHandler.getNNuvegaArrayProperty( NuvegaProperties.PROPERTIES_FILE_NUVEGA_BEAN_NAME);
Example 2.138. Prefer wrapping within call
nuMBeans = NuvegaPropertiesHandler.getNNuvegaArrayProperty( NuvegaProperties.PROPERTIES_FILE_NUVEGA_BEAN_NAME);
Prefer within call arguments
This option lets you define where a line wrap should preferably occur for call arguments that does not fit into the maximal line length. Normally a line gets wrapped before a call argument that don’t fit into the maximal line length. Enabling this option will cause a line break inserted within the call argument for operator expressions when the operator expression is not immediately preceded with or followed by another operator expression.
Since 1.5
Example 2.139. Wrapping method call (default behavior)
failed(output, "a" + "b", null, | "Failed to open prefs: " + e.getMessage()); | |
As you can see from the above example a line break is inserted before the third argument as it would exceed the maximal line length when printed in the same line.
Example 2.140. Prefer wrapping within call argument
failed(output, "a" + "b", null, "Failed to open prefs: " | + e.getMessage()); | |
When the option is enabled, the line break happens within along the operator of the third argument.
Example 2.141. Standard wrapping when two operator expressions
failed(output, "a" + "b", | "Failed to open prefs: " + e.getMessage()); | |
But if two operator expressions follow immediately, the standard behavior applies in order to enhance readability.
Lets you configure the line wrapping behavior for individual elements.
Jalopy supports different wrapping strategies that can be applied to individual elements as required. To configure wrapping for a specific element, locate the element in the tree and select the current strategy. A pop-up menu will open that lets you change the strategy. The preview instantly reflects any change so you can easily recognize what the impact of a different strategy would be. The current available strategies are:
Never wrap
Disables wrapping for a specific element altogether. Please note that disabling wrapping might lead to long lines that exceed the maximal line length and should therefore preferably only be used with certain elements to avoid line wrapping at specific positions.
Example 2.142. Wrapping disabled for import declaration
|
import com.mycompanyname.myprojectname.mypackagename.MyClassName;
|
Example 2.143. Wrapping enabled for import declaration
import com.mycompanyname.myprojectname.mypackagename |
.MyClassName; |
Wrap when necessary
Only wraps when otherwise the maximal line length limit would be exceeded. One could refer to this policy as lower level or late line wrapping. This strategy favors the use of horizontal space and leads to compact code, but might make certain constructs difficult to read because there is sometimes no clear visual boundary between elements when used exclusively.
Example 2.144. Wrap only when necessary after assignment
String value = "xxxxxxxxxxxxxxxxxxxxxxx" + "xxxxxxxxxxxxx" | + "xxxxxxxxxxxxx"; |
Example 2.145. Wrap when exceed after assignment
String value = | "xxxxxxxxxxxxxxxxxxxxxxx" + "xxxxxxxxxxxxx" + "xxxxxxxxxxxxx"; |
Wrap when exceed
Wraps if an element would not fit completely into the current line. Think of it as higher level or early line wrapping. This is probably the most balanced strategy when available that combines very readable results with moderate vertical space requirements.
Example 2.146. Wrapped within extends clause when necessary
interface Testable extends Transferable, Recordable, | Playable, Immutable, Serializable { | } |
Example 2.147. Wrapped before extends keyword when exceed
interface Testable | extends Transferable, Recordable, Playable, | Immutable, Serializable { | } |
Wrap all when first wrapped
Forces a line break for all related elements (like declaration parameters) if the first element has been wrapped. This leads to very uniform and readable code at the expense of higher vertical space requirements.
Example 2.148. Wrapped expression when necessary
while ( | "picker".equals(xxxxxxxxxxxxxxxxxxxxxxxxxx.getName()) | && m.isStatic() && m.isPublic() && m.isFinal()) { | ... | } |
Example 2.149. Wrapped all operators as first operand wrapped
while ( | "picker".equals(xxxxxxxxxxxxxxxxxxxxxxxxxx.getName()) | && m.isStatic() | && m.isPublic() | && m.isFinal()) { | ... | } |
Wrap all when exceed
Similar to Wrap all when first wrapped, but forces a line break for all related elements (like declaration parameters), if the whole element would not fit into the current line.
Example 2.150. Wrapped expression when necessary
_userDatabase.addUser( | "John", "Doo", encryptPassword("password", secretKey), | "123 Nashville", "Surgrass"); |
Example 2.151. Wrapped all operators as first operand wrapped
_userDatabase.addUser( | "John", | "Doo", | encryptPassword("password", secretKey), | "123 Nashville", | "Surgrass"); |
Force wrap
Always wraps a specific element or elements (like call arguments). This can be useful to ensure a consistent style e.g. for chained calls or parameter lists, but also to force line breaks at unusual positions that would normally not be considered during line wrapping.
Please note that not all strategies apply to all elements, and therefore you might be presented with a different set of strategies for each element. Below you find all currently available elements listed along with some short examples of the output with different wrapping strategies.
Import declaration
For import declarations you can choose whether they should be wrapped along the dots if otherwise the maximal line length would be exceeded or not at all.
Since 1.4
Example 2.154. Very long import declaration
|
import com.mycompanyname.myprojectname.mypackagename.MyClassName;
|
Example 2.155. Wrapped import declaration
import com.mycompanyname.myprojectname.mypackagename |
.MyClassName; |
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Before declaration keyword
Lets you choose to force a line break before class
,
interface
enum
and
@interface
keywords or disable line wrapping completely.
Since 1.4
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
After class keyword
Lets you force a line break after the class
keyword or
disable line wrapping altogether.
Since 1.3
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Before extends keyword
Lets you either force a line break before the extends keyword of class/interface/enum declarations, only print a line break if the extends clause would not completely fit into one line, or print a line break only if the extends clause would otherwise exceed the maximal line length. Only wrapping when absolutely necessary will require the least vertical space and yield the most compact code, but readability might be affected.
Example 2.160. Wrapping necessary
interface InterfaceWithAHugeAndSillyName | extends Amicable, Adorable { | ... | } |
Enforcing a line break before the keyword if the complete clause would not fit into one line, provides a good balance between readability and space requirements.
Example 2.161. Extends clause does not fit into one line
| interface Testable extends Transferable, Recordable, Playable { | ... | } |
Example 2.162. Line break because extends clause would not fit into one line
interface Testable | extends Transferable, Recordable, Playable { | ... | } |
Always enforcing a line break before the keyword might be a viable strategy to achieve the most consistent behavior at the expense of slightly higher vertical space requirements.
Example 2.163. No line wrapping necessary
interface Enyoyable extends Amicable, Adorable { | ... | } |
You can control the space printed before the keyword via the indentation settings. See “Extends indent size” for more information. For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
After extends types
Lets you configure the wrapping behavior for the type names of extended classes.
Example 2.165. Class/interface extends types
public interface Channel extends Puttable, Takable { ... }
Example 2.166. Wrapped class/interface extends types (Endline indented)
public interface Channel extends Puttable, Takable { ... }
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Before implements keyword
Forces a line break before the implements keyword of a class declaration.
Example 2.167. implements keyword
public class SynchronizedBoolean implements Comparable, Cloneable { ... }
Example 2.168. Wrapped implements keyword (Standard indented)
public class SynchronizedBoolean implements Comparable, Cloneable { ... }
You can control the space printed before the keyword via the indentation settings. See “Implements indent size” for more information. For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
After implements types
Forces a line wrap after each type name of the implemented classes.
Example 2.169. Class implements types
public class SynchronizedBoolean implements Comparable, Cloneable { ... }
Example 2.170. Wrapped class implements types (Endline indented)
public class SynchronizedBoolean implements Comparable, Cloneable { ... }
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Before throws keyword
Forces a line break before the throws keyword of a method/constructor declaration.
Example 2.171. throws keyword
private File getDestinationFile(File dest, String packageName, String filename) throws IOException { ... }
Example 2.172. Wrapped throws keyword (Endline indented)
private File getDestinationFile(File dest, String packageName, String filename) throws IOException { ... }
You can control the space printed before the keyword via the indentation settings. See “Throws indent size” for more information. For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
After throws keyword
Forces a line break after the throws
keyword.
Since 1.3
Example 2.174. Throws signature (wrapped)
public void foo() throws FooException, BarException { ... }
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
After throws types
Forces a line wrap after each type name of the throws clause of a method/constructor declaration.
Example 2.175. throws types
private File getDestinationFile(File dest, String packageName, String filename) throws IOException, FooException { ... }
Example 2.176. Wrapped throws types (Standard indented)
private static final File getDestinationFile(File dest, String packageName, String filename) throws IOException, FooException { ... }
Example 2.177. Wrapped throws types (Endline indented)
private File getDestinationFile(File dest, String packageName, String filename) throws IOException, FooException { ... }
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
After enum constant
When enabled, forces a line break after each enum constant of an enum declaration.
Since 1.2
Example 2.179. Forced line break after enum constants
public enum Season { WINTER, SPRING, SUMMER, FALL }
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Before field name
Forces a line wrap before the name of an instance field declaration. Please note that this option does not apply for multi-variables.
Since 1.2
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
After multi variable type
When enabled, a line break will be printed after the type identifier of the declaration.
Since 1.0
Example 2.183. Force wrap after type of multi-variables (Standard indented)
BigInteger q = null, p = null, g = null;
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
After multi variable declarator
When enabled, each declaration of a multi-variable declaration gets always printed on a new line. Otherwise, wrapping only occurs when necessary.
Since 1.0
Example 2.185. Force wrap after each declarator of multi-variables (Endline indented)
BigInteger q = null, p = null, g = null;
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Before method name
Forces a line wrap before the name of a method or constructor declaration.
Since 1.0.3
Example 2.187. Method declaration with line break between return type and name
public static int foo() { ... }
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Parameters
Forces a line break after each parameter of a method or constructor declaration.
Example 2.188. Method declaration parameters
public static File create(File file, File directory, int backupLevel) throws IOException { ... }
Example 2.189. Wrapped method declaration parameters (Endline indented)
public static File create(File file, File directory, int backupLevel) throws IOException { ... }
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Chained method call
Lets you either force a line break before each call chain, preferably print a line break before a call chain if the whole call cannot be printed in just one line, only print a line break before a call chain when absolutely necessary to avoid breaking the line length limit, or disable line wrapping before call chains altoghether.
You can (and probably should) have the individual call chains aligned for enhanced readability. See below for instructions how to achieve such a style
Strictly enforcing a line break before each call chain is the simplest strategy, and leads to very uniform and easy to read code, but has the highest vertical space requirements.
Example 2.190. Wrap always
buf.append("xxxxxxxxxxxxxxx") .append("xxxxx") .insert(0, "xxxxxxxxxxxxxx") .append("xxx") .insert(0, "xxx");
Wrapping all chains when the whole expression would not fit into one line, provides the best compromise between enhanced readability and vertical space requirements.
Example 2.191. Wrap all when exceed
method("setName").withParameterTypes(String.class) | .in(person) | .invoke("Luke"); | | field("name").ofType(String.class).in(person).set("Anakin"); |
Preferably wrapping before the call chain if the whole chain cannot be printed in one line, is the most sensible approach if you want a more compact, yet readable result.
Example 2.192. Wrap when exceed
buf.append("xxxxxxxxxxxxxxx").append("xxxxx") .insert(0, "xxxxxxxxxxxxxx").append("xxx").insert(0, "xxx");
Simply wrapping when necessary is not recommended as it favors wrapping on the lower level. Code is often even more compact, but readability might be compromised.
Example 2.193. Wrap when necessary
buf.append("xxxxxxxxxxxxxxx").append("xxxxx").insert(0, "xxxxxxxxxxxxxx").append("xxx").insert(0, "xxx");
Disable wrapping for chained calls might lead to code lines crossing the line length limit, but naturally requires the least vertical space.
Example 2.194. Wrap never
| message.format(ERROR_SOURCE_ADDRESS).param(m_session.getAimName()).send(); | buf.append("xxxxxxxxxxxxxxx").append("xxxxx").insert(0, | "xxxxxxxxxxxxxx").append("AAA").insert(0, "xxx"); |
Disabling wrapping before call chains altogether, only makes a difference for calls without arguments. Otherwise, wrapping may still happen within the argument list, as you can see in the above example.
You can control the indentation for chained method calls with either “Indent dotted expressions” or “Align chained method calls”. For enhanced readability, it’s probably best to have chained calls aligned. Otherwise wrapped calls will be indented with the current indentation strategy.
Example 2.195. Standard indented chained method call
buf.append("xxxxxxxxxxxxxxx") .append("xxxxx") .insert(0, "xxxxxxxxxxxxxx") .append("xxx") .insert(0, "xxx");
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Nested chained method call
Lets you either force a line break before each nested call chain, preferably print a line break before a call chain if the whole call cannot be printed in just one line, only print a line break before a call chain when absolutely necessary to avoid breaking the line length limit, or disable line wrapping before nested call chains altogether.
Since 1.6
You can (and probably should) have the individual call chains aligned for enhanced readability. See below for instructions how to enable chain alignment
Strictly enforcing a line break before each nested call chain is the simplest strategy, and leads to very uniform and easy to read code, but has the highest vertical space requirements.
Wrapping all chains when the whole expression would not fit into one line, provides the best compromise between enhanced readability and vertical space requirements.
Example 2.197. Wrap all when exceed
mix(new DrinkBuilder().add("tequila") | .withRocks() | .withSalt() | .drink()); | | mix(new DrinkBuilder().add("juice").withRocks().drink()); |
Preferably wrapping before a call chain if the whole chain cannot be printed in one line, is the most sensible approach if you want a more compact, yet readable result.
Example 2.198. Wrap when exceed
mix(new DrinkBuilder().withIce() .drink("special flavored spiced rum", 50));
Simply wrapping when necessary is not recommended as it favors wrapping on the lower level. Code is often even more compact, but readability might be compromised.
Example 2.199. Wrap when necessary
mix(new DrinkBuilder().withIce().drink( "special flavored spiced rum", 50));
Disable wrapping for chained calls might lead to lines crossing the line length limit, but naturally requires the least vertical space. Wrapping may still happen within the argument list.
You can control the indentation for chained method calls with either “Indent dotted expressions” or Section 2.8.8.2.3, “Nested chained method calls”. For enhanced readability, it’s probably best to have chained calls aligned. Otherwise wrapped calls will be indented with the current indentation strategy.
Please note that you can control the alignment for chained method calls with the Section 2.8.8.2.3, “Nested chained method calls” option. For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Example 2.201. Chained method call
message.format(ERROR_SOURCE_ADDRESS).param (m_session.getAimName()).send();
Example 2.202. Wrapped chained method call (aligned)
message.format(ERROR_SOURCE_ADDRESS) .param (m_session.getAimName()) .send();
Call arguments
Forces a line break after each argument of a method call.
Example 2.203. Method call
doSomething(); _userDatabase.addUser("Name", encryptPassword("password", _secretKey), "123 fake address"); doSomethingElse();
Example 2.204. Wrapped method call (Endline indented)
doSomething(); _userDatabase.addUser("Name", encryptPassword("password", _secretKey), "123 fake address"); doSomethingElse();
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Nested call arguments
Forces a line wrap after each argument of a method call if at least one argument is a method call itself. This option can prove especially useful if one prefers to nest method calls as arguments rather than adding local variables just to hold those arguments.
Example 2.205. Wrapped nested method call (Endline indented)
doSomething(); _userDatabase.addUser("Name", encryptPassword("password", _secretKey), "123 fake address"); doSomethingElse();
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Marker annotation
Lets you control the wrapping behavior of marker annotations. Marker annotations are
annotations with no elements, e.g. @Preliminary
. There are four
strategies you can choose from:
Wrap when necessary | Only issue a line break after a marker annotation if otherwise the maximal line length limit would be exceeded |
Wrap when exceed | Issue a line break after a marker annotation if the declaration does not fit within the maximal line length. Requires all marker annotations to appear before all other modifiers |
Wrap last | Issue a line break after the last marker annotation. Requires all marker annotations to appear before all other modifiers |
Wrap always | Issue a line break after each marker annotation. Requires all marker annotations to appear before all other modifiers |
You can ensure that marker annotations appear before other Java modifiers via the modifier sorting settings, see Section 2.8.11.2, “Modifiers” for more information
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Since 1.1
Example 2.208. No line break after marker annotation when modifier(s) before
public @Preliminary class TimeTravel { ... }
Parameter marker annotation
Lets you control the wrapping behavior of marker annotations that appear within declaration parameters. There are two strategies you can choose from:
Wrap never | Never issue a line break after a marker annotation |
Wrap when necessary | Only issue a line break after a marker annotation if otherwise the maximal line length limit would be exceeded |
The second strategy only makes sense when using one of the endline indentation strategies. Otherwise line wrapping will preferably happen after the left parenthesis when necessary.
Since 1.9.3
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
After left parenthesis
Lets you control the wrapping behavior of the left parenthesis of normal and single-member annotations. You can avoid a line break altogether, only print a line break if the annotation would otherwise exceed the maximal line length, or print a line break whenever an annotation takes more than just one line.
Never wrapping is the best choice when using Section 2.8.8.1.1, “Strict Endline”, but with the other indentation strategies it depends on your preference and the annotations you use whether a line break is desirable. If you don’t want to disable wrapping for annotations altogether, it is recommended to allow a line break after the left parenthesis.
Since 1.9.2
Example 2.211. Never wrap, endline indent
@WebService(name = "com.company.FooDemoService", | targetNamespace = "com.foo.demo") | public interface Foo { | @WebResult(targetNamespace = "com.company.jaxws.space.order") public Receipt placeOrder(Order order); | } |
Example 2.212. Never wrap, standard indent
@WebService(name = "com.company.FooDemoService", | targetNamespace = "com.foo.demo") | public interface Foo { | @WebResult(targetNamespace = "com.company.jaxws.space.order") public Receipt placeOrder(Order order); | } |
Wrapping after the left parenthesis often provides more horizontal space and therefore can keep your annotations within the maximal line limit. When using anything other than Section 2.8.8.1.1, “Strict Endline” you probably want to at least enable this strategy if the line length limit is important.
Example 2.213. Wrap when necessary
@WebService(name = "com.company.FooDemoService", | targetNamespace = "com.foo.demo") | public interface Foo { | @WebResult( | targetNamespace = "com.company.jaxws.space.order") | public Receipt placeOrder(Order order); | } |
Wrap when exceed is the most aggressive strategy that will preferably issue a line break after the left parentheses whenever the annotation will take more than one line. This works best when using “Standard indentation”, but might be desirable otherwise as well. But please note that because of backward compatibility constraints “Wrap before right parenthesis” must be enabled then.
Example 2.214. Wrap when exceed, standard indent
@WebService( | name = "com.company.FooDemoService", | targetNamespace = "com.foo.demo") | public interface Foo { | @WebResult( | targetNamespace = "com.company.jaxws.space.order") | public Receipt placeOrder(Order order); | } |
Example 2.215. Wrap when necessary, mixed endline
@WebService( | name = "com.company.FooDemoService", | targetNamespace = "com.foo.demo") | public interface Foo { | @WebResult( | targetNamespace = "com.company.jaxws.space.order") | public Receipt placeOrder(Order order); | } |
Annotation members
Lets you control the wrapping behavior of the member expressions of normal annotations. You can disable wrapping altogether, only wrap after a member element when really necessary, or force line wrapping after each element. Never wrapping can easily lead to long lines which exceeded the maximal line length, but this might be acceptable.
Since 1.5
Example 2.216. No line break after members
| @WebService(name="FooDemoService", targetNamespace="com.foo.Namespace") public class BitTwiddle { | } |
Please note that for nested annotations, wrapping might still happen depending on your parentheses preferences. If you want to disable wrapping for annotations altogether, you need to set the parentheses options to "Never wrap" as well.
Example 2.217. No line break after members
@Author( | @Name(first = "Joe", last = "Hacker", location = "Redmond") | ) | public class BitTwiddle { ... } |
If the line length limit it important, you should at least enable "Wrap when necessary". This ensures that a line break will occur after an annotation member whenever the next annotation would exceed the maximal line length.
Example 2.218. Wrap when necessary
@WebService(name = "FooDemoService", | targetNamespace = "com.foo.demo.Namespace") | | public class BitTwiddle { ... } |
Taking to the extreme, you can enforce a line break after each annotation member. This takes more vertical space, but leads to very unified and readable code. Probably best to allow wrapping after the left parentheses when not using Section 2.8.8.1.1, “Strict Endline”.
Example 2.219. Force wrap
@WebService( | name = "FooService", | namespace = "com.foo.Namespace") | public class BitTwiddle { ... } |
Example 2.220. Force wrap
@Author( @Name( first = "Joe", last = "Hacker" ) ) public class BitTwiddle { }
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Before right parenthesis
Lets you control the wrapping behavior of the right parenthesis of normal and single-member annotations. You can avoid a line break altogether, only print a line break if the annotation would otherwise exceed the maximal line length, or print a line break whenever an annotation takes more than just one line.
Never wrapping is a good choice from an aesthetical point of view and should suffice for most needs. Only if you are anal about the maximal line length limit, you really should select another strategy.
Since 1.9.2
Example 2.221. Never wrap, endline indent
@WebService(name = "com.company.FooDemoService", | targetNamespace = "com.foo.demo") | public interface Foo { | @WebResult(targetNamespace = "com.company.jaxws.space.order") public Receipt placeOrder(Order order); | }
Example 2.222. Never wrap, standard indent
@WebService(name = "com.company.FooDemoService", | targetNamespace = "com.foo.demo") | public interface Foo { | @WebResult(targetNamespace = "com.company.jaxws.space.order") public Receipt placeOrder(Order order); | }
Wrapping before the right parenthesis should be required only on very rare occasions, because preferably a line break should happen after the left parenthesis. But if you absolutely strive to keep lines within the maximal line length limit, you should enable this strategy.
Example 2.223. Wrap when necessary
@WebResult(targetNamespace = "com.company.project.as.jaxws.space.order"| ) | public interface Foo { } |
In case you prefer to let annotation members stand out, you can enable "Wrap when exceed". This way, a line break will be printed before the right parenthesis whenever the annotation list takes more than just one line to print and a line break has been printed after the left parenthesis. You might want to enable the corresponding strategy for the left parenthesis option if you like such a style.
Example 2.224. Wrap when exceed, standard indent
@WebService( name = "com.company.FooDemoService", targetNamespace = "com.foo.demo" )
Operators
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Chained index operator
Lets you specify whether wrapping along the dots of chained index operators should be disabled.
Since 1.0
Note how in the above example wrapping does not occur along the dots of the index operator, but right after the assignment! For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Ternary question
Forces a line wrap after the first operand.
Example 2.227. Wrapped ternary expression question mark (Endline indented)
String comma = spaceAfterComma ? COMMA_SPACE : COMMA;
Indentation for consecutive lines depends on the used indentation scheme. See Section 2.8.8.1.1, “Strategies” for more information. You may further want to use continuation indentation. For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Ternary colon
Forces a line wrap after the second operand.
Example 2.228. Wrapped ternary expression colon (Endline indented)
String comma = spaceAfterComma ? COMMA_SPACE : COMMA;
If both switches are disabled, ternary expressions are printed in one line (if everything fits in one line, that is).
If both switches are enabled, you can force a style like the following:
Example 2.230. Wrapped ternary expressions (Standard indented)
String comma = spaceAfterComma ? COMMA_SPACE : COMMA;
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Qualifiers
Lets you specify whether wrapping along the dots of qualifiers should be disabled.
Since 1.0
Note how in the above example, wrapping does not occur along the dots of the qualifier, but before the method call! For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Dotted expression
Lets you specify whether wrapping along dotted expressions should be disabled. This option covers all dotted expressions not handled by the more specific options for chained method calls, index operators or qualifiers (see above). The option is enabled by default for compatibility reasons. If you’re serious about the maximal line length limit, we recommend to disable the option.
Since 1.5
Example 2.233. Wrapped dotted expression
boolean test = ((com.foo.highfly.test.internal.Foo) container) |
.transportDebugFlag; |
|
Example 2.234. Dotted expression (wrapping disabled)
boolean test = |
((com.foo.highfly.test.internal.Foo) container).transportDebugFlag;
|
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
After assignment
Lets you control the way wrapping takes action for assignments. If left disabled, line wrapping preferably occurs as part of the expression printing. Otherwise wrapping will be performed right after the assignment whenever the expression cannot be printed in just one line.
Example 2.235. Prefer wrap along the expression
this.interessentenNr = new InteressentenNr( Fachschluesselerzeugung.createService() .getNeuerFachschluessel( FachschluesselerzeugungService.FACHSCHLUESSEL_KZ_INTERESSENT ) );
Example 2.236. Prefer wrap after assignment
this.interessentenNr = new InteressentenNr( Fachschluesselerzeugung.createService() .getNeuerFachschluessel( FachschluesselerzeugungService.FACHSCHLUESSEL_KZ_INTERESSENT ) );
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
After return
Lets you control the wrapping behavior for return statements. When enabled, a line break is inserted after the return statement when the expression would exceed the maximal line length.
Since 1.2.1
Example 2.237. return statement
return ((getKey() == null) ? (other.getKey() == null) | : getKey().equals(other.getKey())); |
Example 2.238. Prefer wrapping after return statement
return | ((getKey() == null) ? (other.getKey() == null) | : getKey().equals(other.getKey())); |
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
After left parenthesis
Lets you control the wrapping behavior for parameter, statement and expression lists. When left disabled, the first line break will be preferably inserted behind the first parameter or expression and only occurs after the left parenthesis if the maximal line length would be otherwise exceeded.
Example 2.239. Wrap after left parenthesis (disabled)
appServerReferencesVector.add(new AppServerReference( "RemoteApplicationManager", poa.create_reference_with_id( "RemoteApplicationManager".getBytes(), RemoteApplicationManagerHelper.id())));
When enabled, the line break will always occur behind the left parenthesis when the list parameters, arguments or expressions cannot be printed in just one line.
Example 2.240. Wrap after left parenthesis (enabled)
appServerReferencesVector.add( new AppServerReference( "RemoteApplicationManager", poa.create_reference_with_id( "RemoteApplicationManager".getBytes(), RemoteApplicationManagerHelper.id())));
This option affects the output style of method/constructor declarations and
calls, creator calls and if-else
, for
,
while
and do-while
blocks.
As per default, the wrapped lines will be indented using standard indentation,
but you may want to apply another indentation scheme. See
Section 2.8.8.1.1, “Strategies” for more information.
For general information about the available wrapping strategies, please refer to the
wrapping strategies overview.
Before right parenthesis
Prints a line break before the right parenthesis of parameter or expression
lists when at least one parameter/expression was wrapped. The parenthesis will
be intended according to the current indentation level.
This switch affects the output style of method/constructor declarations and
calls, creator calls and if-else
, for
,
while
and do-while
blocks.
Example 2.241. Right parenthesis (disabled)
public void severalParameters(String one, int two, String three, StringObject four, AnotherObject five) { }
Example 2.242. Right parenthesis (enabled)
public void severalParameters(String one, int two, String three, StringObject four, AnotherObject five ) { }
Both switches combined, looks like the following example:
Example 2.243. Left and right parenthesis
appServerReferencesVector.add( new AppServerReference( "RemoteApplicationManager", poa.create_reference_with_id( "RemoteApplicationManager".getBytes(), RemoteApplicationManagerHelper.id() ) ) );
For blocks the output may go like this:
Example 2.244. Left and right parenthesis (wrapped)
if ( "pick".equals(m.getName()) && m.isStatic() && m.isPublic() ) { pickFound = true; } else if ( "pick".equals(m.getName()) && m.isStatic() && m.isPublic() ) { pickFound = true; }
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Grouping parentheses
Lets you control the wrapping behavior for grouping parentheses. When enabled, line breaks are inserted after left and before right parentheses of grouped expressions to let the expression(s) stand out.
Example 2.245. Grouping parentheses (standard indented)
if ( !((bankverbindung instanceof ObjectValue) || (bankverbindung instanceof PrimitiveValue)) ) { throw new RuntimeException(); }
Example 2.246. Wrapped grouping parentheses (standard indented)
if ( !( (bankverbindung instanceof ObjectValue) || (bankverbindung instanceof TkPrimitiveValue) ) ) { throw new RuntimeException(); }
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Type parameter
When enabled, type parameters of parametrized (generic) types are wrapped, when necessary.
Since 1.4
Example 2.247. Parameterized type that lead to exceeded maximal line length
| private final Map<Short, String> example = new HashMap<Short, String>(); |
Example 2.248. Wrapped parameterized type (endline indented)
| private final Map<Short, String> example = new HashMap<Short, | String>(); | |
Please note that with Endline indentation enabled, wrapping only happens if both type parameter names are either not single-lettered or contain one ore more bounds.
Example 2.249. Exceptions when using endline indentation
| public class Test<A, B extends Comparable<B> & Cloneable> { } |
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Labels
Forces a line wrap after labels.
Example 2.250. Label
// advance to the first CLASS_DEF or INTERFACE_DEF LOOP: for (AST child = tree.getFirstChild(); child != null; child = child.getNextSibling()) { switch (child.getType()) { case JavaTokenTypes.CLASS_DEF : case JavaTokenTypes.INTERFACE_DEF : next = child; break LOOP; default : break; } }
Example 2.251. Wrapped label (Standard indented)
// advance to the first CLASS_DEF or INTERFACE_DEF LOOP: for (AST child = tree.getFirstChild(); child != null; child = child.getNextSibling()) { switch (child.getType()) { case JavaTokenTypes.CLASS_DEF : case JavaTokenTypes.INTERFACE_DEF : next = child; break LOOP; default : break; } }
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Registry Keys
Forces line wrapping after assignments of public constants that are defined in a class whose name ends with the “Registry” suffix.
Since 1.7
Example 2.252. Registry keys
class FooRegistry { public final static boolean ALLOW_FAKE_FOOS = "com.company.layer.Foo"; }
Example 2.253. Registry keys (wrapping forced)
class FooRegistry { public final static boolean ALLOW_FAKE_FOOS = "com.company.layer.Foo"; }
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
After parameters/expressions
When enabled, this switch will cause all parameters/expressions to be wrapped, if and only if the first parameter/expression of the list has been wrapped.
Example 2.254. Expression list (all wrapped)
if ( "pick".equals(m.getName()) && m.isStatic() && m.isPublic() ) { pickFound = true; } else if ( "pick".equals(m.getName()) && m.isStatic() && m.isPublic() ) { pickFound = true; }
For general information about the available wrapping strategies, please refer to the wrapping strategies overview.
Contains options to control the wrapping behavior for arrays.
Wrap as needed
Enabling this option means cause line breaks to be inserted, whenever an element would otherwise exceed the maximal line length limit.
Example 2.255. Wrap as needed
String[] s = new String[] { | "first", "second", "third", "fourth",| "fifth", "sixth", "seventh", | "eighth", "ninth", "tenth", | }; |
Wrap all when exceed
Forces a line break after every array element when all elements would not fit into the current line limit.
Since 1.7
Example 2.256. All elements fit into line
String[] s = new String[] { | "first", "second", "third", "fourth", "fifth", "sixth", "seventh",| }; |
Example 2.257. Wrap all elements when line would get exceeded
String[] s = new String[] { | "first", | "second", | "third", | "fourth", | "fifth", | "sixth", | "seventh", | "eighth", | }; |
Wrap after element
Forces a line break after every n-th element.
Example 2.258. Wrap after element 1
String[] s = new String[] { | "first", | "second", | "third", | "fourth", | "fifth", | "sixth", | "seventh", | "eighth", | "ninth", | "tenth", | };
Please note that no checking is done regarding the maximal line length limit which might easily lead to lines exceeding the maximal line length when you set n to something bigger than '1'.
Example 2.259. Wrap after element 3
String[] s = new String[] { | "first", "second", "third",| "fourth", "fifth", "sixth",| "seventh", "eighth", "ninth", "tenth", | } |
If neither option is enabled, the array elements will be printed in one line, right after the left curly brace, i.e. automatic line wrapping will be disabled.
Please note that you can further customize the wrapping behavior for arrays with the following options: