Skip to content

consider convention principle for disableAllWarnings=true #5367

@Pankraz76

Description

@Pankraz76

Considering:

it feels overwhelming and impractical to require explicitly setting disableAllWarnings=true.
This should actually be part of a convention-based default to avoid unpleasant situations like the one recently discovered in Spotless.

In fact, this should be the default, because:

  • Having thousands of warnings simply does not scale on a human level.
  • It is unrealistic to expect developers to spend time dealing with such a volume of noise.
    Most won’t have the time—or the motivation—to address it. Instead, the logs get flooded, attention gets diluted, and the natural reaction is to ignore the warnings entirely.
  • Endless, repeating warnings create alert fatigue. The more noise a tool produces, the less likely real issues will ever be noticed.
  • Warnings should be actionable by default.
    If they aren’t, developers shouldn’t have to manually opt out. Tools should provide clean, helpful feedback out of the box.
  • A tool that produces more noise than value becomes counterproductive.
    Reducing irrelevant output is essential to maintaining a healthy signal-to-noise ratio.

From this perspective, having disableAllWarnings=true as the default would establish a more sensible, error-focused baseline.
Developers could then intentionally opt in to warnings when they want to focus on quality checks or refactoring, instead of being overwhelmed by default.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions