Coding Style: Formatter barrier

FORMATTER BARRIER

Trailing line comment (//) can be used as a formater barrier to prevent automated formaters or IDEs from collapsing or reflowing long fluent chains. This convention has been used successfully in production codebases for more than decade, including in large and continuously evolving systems, without causing semantic issues or tooling problems. Its primary benefit is preserving the visual structure of code across edits and refactoring, which significantly improves readability, code review quality, and long-term maintainability; it also helps reviewers more easily identify flawed logic or misunderstandings during code review. Maintaining a stable visual layout supports developers (especially those who rely on visual patterns when reading and reasoning about code) in recognizing intent, spotting inconsistencies, and retaining structural understanding even after substantial changes. This practice affects only formatting, has no impact on compilation or runtime behavior.
Tools already treats comments as layout anchors!

Just compare:

public static <D extends IcdCodeGet & Comparable<D>, L extends IcdListAccess & Comparable<L>> IcdCodeGet[] getBestCodes( //
      ComparableList<ComparableLink<L, IcdCodeGet[]>> bests //
      , L list //
      , boolean renew //
      , ExtendedIterator<CounterCmp<D>> statsSource) {...}

with:

public static <D extends IcdCodeGet & Comparable<D>, L extends IcdListAccess & Comparable<L>> IcdCodeGet[] getBestCodes( ComparableList<ComparableLink<L, IcdCodeGet[]>> bests, L list, boolean renew, ExtendedIterator<CounterCmp<D>> statsSource) {...}

This gives us freedom to auto colapse arguments and uncollapse them manually when needed.