I propose updating our Eclipse code formatter configuration (icellmobilsoft-eclipse-code-formatter.xml) to improve code readability and compactness.
Current Behavior & Issue: Currently, there is a divergence in formatting policies between our branches:
The release branch uses the COMMON_LINES setting, which often forces unnecessary line breaks even for short statements.
The master branch uses PRESERVE_LINES (preserve positions), which allows for inconsistent formatting depending on individual developer habits.
Proposed Change: We should switch the wrapping policy to SEPARATE_LINES_IF_WRAPPED for major code structures (Method Declarations, Method Invocations, Allocations, Enum Constants, etc.).
Reasoning:
-
Uniformity: This resolves the conflict between the release and master branch configurations.
-
Responsiveness: The formatter will only break lines when they exceed the configured line width (e.g., 150 chars).
-
Compactness: Unlike COMMON_LINES, short and readable statements will remain on a single line, reducing vertical noise.
-
Automation: Unlike PRESERVE_LINES, it enforces a standard structure without relying on manual line breaks.
Example: Instead of forcing this on short lines:
callMethod(
param1,
param2
);
It should allow this (if it fits):
callMethod(param1, param2);
I propose updating our Eclipse code formatter configuration (icellmobilsoft-eclipse-code-formatter.xml) to improve code readability and compactness.
Current Behavior & Issue: Currently, there is a divergence in formatting policies between our branches:
The release branch uses the COMMON_LINES setting, which often forces unnecessary line breaks even for short statements.
The master branch uses PRESERVE_LINES (preserve positions), which allows for inconsistent formatting depending on individual developer habits.
Proposed Change: We should switch the wrapping policy to SEPARATE_LINES_IF_WRAPPED for major code structures (Method Declarations, Method Invocations, Allocations, Enum Constants, etc.).
Reasoning:
Uniformity: This resolves the conflict between the release and master branch configurations.
Responsiveness: The formatter will only break lines when they exceed the configured line width (e.g., 150 chars).
Compactness: Unlike COMMON_LINES, short and readable statements will remain on a single line, reducing vertical noise.
Automation: Unlike PRESERVE_LINES, it enforces a standard structure without relying on manual line breaks.
Example: Instead of forcing this on short lines:
It should allow this (if it fits):
callMethod(param1, param2);