Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Naming convention for scan rule constants in library packages

Aperta
  • Qualcosa non va?
#142 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java
Ambito
tooling

Direzione di ricerca

Read the suggested convention options in the issue and check Ballerina's annotation rules for whether a constant mapping can be accessed in an annotation. Compare the namespace, completion, documentation, and import tradeoffs for each option; the issue is done when a convention is agreed on for rule constants across library packages.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Area/Core Type/Improvement
Current Limitation

  • A @scan:Suppress annotation names rules by ID, such as ballerina:2 or ballerina/http:1, which does not say what is suppressed.

  • ballerina/scan is adding a constant for each core rule, named after the finding it suppresses, so the annotation reads as what is suppressed and why:

    @scan:Suppress {rules: [scan:UNUSED_FUNCTION_PARAMETER], reason: "Required by the listener interface"}

  • Packages that provide scan rules through an analyzer, such as the standard libraries, should provide constants for their rules too. Unlike ballerina/scan, whose API is only about scanning, a library's rule constants share its namespace with the rest of its API. Without a convention:

    • a rule constant can clash with, or be mistaken for, an existing API constant of the library;
    • completion and the API docs mix rule constants with the API;
    • each library names them differently.

  • A plain prefix such as SCAN_ solves those, but breaks the finding-based reading: http:SCAN_UNSECURED_RESOURCE reads as "scan unsecured resource" rather than "suppress the unsecured resource finding".

Suggested Improvement

Agree on a convention for rule constants in library packages, so that they read as the finding, stay apart from the library's API, and look the same in every library. Options to discuss (rule names are illustrative):

  1. No prefix, named after the finding: http:UNSECURED_RESOURCE. Reads best; relies on the name not clashing with the API and on the docs marking it as a rule.
  2. A suffix: http:UNSECURED_RESOURCE_RULE.
  3. A constant mapping of rules: http:SCAN_RULES.UNSECURED_RESOURCE. Groups the rules under one name; needs checking that member access on a constant mapping is accepted in the annotation.
  4. A separate module of the library, such as ballerina/http.rules: keeps the rules out of the main API, but needs an extra import in every file that suppresses a rule.
Version

0.13.0-SNAPSHOT

Lingua principale
Java
Stelle
15
Fork
12
Merge medio
2g 2h
PR unite (30g)
11

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ballerina-platform/static-code-analysis-tool

Tutte le issue di ballerina-platform/static-code-analysis-tool

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.