Qodana’s public‑access detection depends on naming conventions, raising ambiguity for explicit visibility declarations

Recommendation

Do not add a blanket, Qodana-wide public declaration. If a team needs explicit API visibility, add a narrowly scoped, language-specific inspection that checks an existing visibility mechanism or a supported annotation—not a new rule that changes the meaning of every identifier without a leading underscore.

A dedicated rule is justified for modules with strict internal-boundary policies. It is not justified as default behavior across languages.

Established behavior and the likely explanation

Qodana runs language-specific IntelliJ inspections; it does not define one universal access-control model. Java and Kotlin already express public, private, and internal in source code. For those languages, an additional Qodana declaration would usually duplicate existing checks rather than fill a language-level gap.

The premise that every identifier without a leading underscore is public should be treated as a version- and plugin-specific hypothesis, not a general Qodana fact. A convention-based inspection may use that heuristic, but Python-style underscore conventions and JavaScript or TypeScript visibility controls are not equivalent. If such a heuristic currently marks internal members as public, the likely explanation is that the relevant inspection uses naming as a proxy for API status.

How the rule could be expressed

Option	Appropriate use	Main limitation
Existing language modifier and inspection	Default choice when the language already supports explicit visibility	May not express a team-specific API policy
Custom inspection	Enforcing a required declaration in selected modules	Requires parsing, severity, suppression, and baseline design
Annotation	Machine-readable declaration supported by the language plugin	May require source changes and plugin-specific support
Comment marker	Only when the plugin can parse it reliably	Fragile under formatting, code movement, or generated files
Inspection severity toggle	Adjusting an existing diagnostic	Does not create a new declaration mechanism

Do not invent a generic annotation or configuration key. Exact inspection names, YAML properties, and suppression syntax depend on the installed Qodana release and language plugin.

Effect on existing rule sets

• Expect possible duplicate findings where naming and visibility inspections overlap.
• Define severity, module scope, suppression behavior, and baseline handling before enabling the rule.
• Keep a candidate rule opt-in until it is tested against real repositories.
• Budget for documentation, false-positive tuning, and maintenance when language plugins change.

Verification before implementation

1. Record the installed Qodana version and identify the target language plugin. Review the bundled inspection profile and the project’s qodana.yaml for existing visibility or naming inspections.
2. Create a small sample containing public, private or internal, underscore-prefixed, and explicitly marked members. Run the project’s existing Qodana command and compare the SARIF or HTML reports before and after a prototype.
3. Check whether the existing inspection already captures the intended policy and whether new findings would duplicate existing baseline entries.

This recommendation assumes Qodana is operating as an inspection runner with a language-specific plugin; current configuration details still require verification. One diagnostic detail would materially change the recommendation: which language plugin is the policy intended for?