What's changed?

Add three new SLF4J recipes to Slf4jBestPractices:

• StringFormatToParameterizedLogging — Replaces String.format() calls in SLF4J logging statements with parameterized {} placeholders.
• MessageFormatToParameterizedLogging — Replaces MessageFormat.format() calls in SLF4J logging statements with parameterized {} placeholders.
• RemoveUnnecessaryLogLevelGuards — Removes if (logger.isDebugEnabled()) guards around SLF4J logging calls when parameterized logging makes them unnecessary.

The StringFormat and MessageFormat recipes are ordered before the existing ParameterizedLogging recipe in slf4j.yml so that format calls are converted to parameterized logging first, before ParameterizedLogging handles string concatenation.

What's your motivation?

String.format() and MessageFormat.format() defeat the purpose of SLF4J's parameterized logging by eagerly formatting the message regardless of log level. The existing ParameterizedLogging recipe handles string concatenation but not these cases.

Similarly, once logging statements use parameterized {} placeholders, explicit isDebugEnabled()/isTraceEnabled() guards become unnecessary boilerplate since SLF4J defers argument evaluation.

Anything in particular you'd like reviewers to focus on?

• The RemoveUnnecessaryLogLevelGuards recipe only removes guards when all logging calls inside the guard body use parameterized logging (no string concatenation or method calls other than toString()).

Anyone you would like to review specifically?

@timtebeek saw these recipes as I was developing them in Liftwizard:

• liftwizard#3336 — Add StringFormatLoggingToParameterized, MessageFormatLoggingToParameterized, and RemoveUnnecessaryLogLevelGuards recipes
• liftwizard#3343 — Rename logging recipes to ToParameterizedLogging naming convention
• liftwizard#3484 — Handle concatenated string literal format arguments in logging recipes

Have you considered any alternatives or workarounds?

I considered splitting this into two PRs and I could still do that if preferred.

• One for the two formatted strings to parameterized logging recipes.
• One for unnecessary log level guards.

Any additional context

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files