Skip to main content

Code style configuration

When you run recipes with the Moderne CLI, the results are formatted according to the code styles stored in each repository's LST. By default, the CLI auto-detects styles by analyzing the existing source code — it counts occurrences of certain patterns (tabs vs. spaces, brace placement, etc.) and the most common pattern wins each style rule.

This detection works well for most projects, but it can produce inaccurate results when a codebase is inconsistent or when you want to enforce a specific standard regardless of what the existing code looks like. You may also have a shared Checkstyle configuration or custom OpenRewrite styles that you want to apply across all repositories.

In this guide, you will learn how to explicitly configure Checkstyle and OpenRewrite style files so that they are attached to LSTs during builds. Explicitly configured styles take precedence over auto-detected ones, giving you full control over how recipe results are formatted.

How styles are applied during builds

During a single mod build, styles from all configured sources are merged. When two sources define the same formatting rule, the one with higher precedence wins:

  1. Auto-detected styles inferred by analyzing patterns in the existing source code (lowest precedence)
  2. Configured Checkstyle styles from mod config build style checkstyle
  3. Configured OpenRewrite styles from mod config build style openrewrite (highest precedence)

This means your explicitly configured styles will override any auto-detected ones, and OpenRewrite styles will override Checkstyle styles when both define the same formatting rules.

Configuring OpenRewrite styles

For the most fine-grained control over code formatting, you can provide an OpenRewrite style YAML file. OpenRewrite styles can express formatting preferences that go beyond what Checkstyle covers, such as import ordering, brace placement, and whitespace rules. These styles have the highest precedence.

Setting the OpenRewrite style file

mod config build style openrewrite edit /path/to/rewrite.yml

The path can be absolute, relative, use tilde expansion (~/rewrite.yml), or reference an environment variable (${REWRITE_STYLE}). When using an environment variable, the variable is resolved at build time.

The YAML file should follow the OpenRewrite style format. Here is an example:

type: specs.openrewrite.org/v1beta/style
name: com.example.MyCodeStyle
displayName: My organization code style
description: Custom formatting rules for our codebase.
styleConfigs:
- org.openrewrite.java.style.TabsAndIndentsStyle:
useTabCharacter: false
tabSize: 4
indentSize: 4
continuationIndent: 8

Viewing OpenRewrite configuration

mod config build style openrewrite show

Removing OpenRewrite configuration

mod config build style openrewrite delete

Once removed, the previously configured OpenRewrite styles no longer apply. If no Checkstyle configuration is set either, the CLI falls back to auto-detecting styles.

Configuring Checkstyle

If your organization uses a Checkstyle configuration XML file, you can point the CLI to it so that the rules are parsed into OpenRewrite styles and included in every LST build. Checkstyle styles sit between auto-detected and OpenRewrite styles in the precedence order.

Setting the Checkstyle configuration

mod config build style checkstyle edit /path/to/checkstyle.xml

The path can be absolute, relative, use tilde expansion (~/checkstyle.xml), or reference an environment variable (${CHECKSTYLE_CONFIG}). When using an environment variable, the variable is resolved at build time.

Viewing Checkstyle configuration

mod config build style checkstyle show

Removing Checkstyle configuration

mod config build style checkstyle delete

Once removed, the previously configured Checkstyle rules no longer apply. If no OpenRewrite styles are configured either, the CLI falls back to auto-detecting styles.

Additional reading