Validare nomi feature flag

Questa capacità convalida un nome candidato rispetto a uno schema pratico di settore: non vuoto, tutto in minuscolo, in kebab-case con trattini o in snake_case (mai entrambi i separatori nella stessa stringa), almeno due segmenti, prefisso descrittivo come enable, feature, ff, rollout o beta, al massimo sessantaquattro caratteri e senza separatori ai bordi né consecutivi. L'input vuoto fallisce con invalid_input e non viene addebitato. Le violazioni di convenzione restituiscono un payload di successo con valid impostato a false e un elenco ordinato di issues così che l'integrazione continua possa far fallire la build con un report chiaro.

Cosa richiede la convenzione di nomenclatura

Primo, non deve essere vuoto né solo spazi: un nome vuoto viene rifiutato subito come invalid_input perché non c'è nulla di utile da valutare. Secondo, ogni carattere deve essere lettera ASCII minuscola, cifra ed esattamente uno stile di separatore: trattini per il kebab-case oppure underscore per lo snake_case. Insieme, queste regole si allineano a chiavi in stile LaunchDarkly, toggle Unleash e alla maggior parte dei file JSON o YAML interni senza inventare un dialetto di un solo fornitore.

Contratto di input, forma della risposta ed errori

In caso di successo la risposta include sempre valid (booleano), il name dopo trim, style (kebab, snake o null se il pattern non è classificato), prefix (primo segmento o null), segments come array ordinato di stringhe, segment_count, has_descriptive_prefix, issues come elenco stabile e ordinato di codici leggibili da macchina, e una breve frase convention adatta all'interfaccia. Quando il nome è presente ma viola la convenzione, valid è false e issues elenca codici come not_lowercase, mixed_separators, missing_descriptive_prefix, too_few_segments, invalid_characters, consecutive_separators, leading_or_trailing_separator, too_long, missing_separator_segments o invalid_pattern—senza lanciare eccezioni—così linter e bot di pull request stampano tutti i problemi in una volta. Solo nomi vuoti, assenti o non stringa lanciano invalid_input; tali fallimenti non consumano il saldo prepagato.

Dove la convalida dei nomi di flag dà valore

I team di piattaforma e di developer experience collegano questo controllo ai generatori di scaffolding affinché non entrino flag nuovi senza prefisso né stile di separatore. I job di integrazione continua scansionano le pull request che toccano cataloghi di flag o file di ambiente di esempio e fanno fallire la build quando un nome confonderebbe gli operatori mesi dopo. Gli strumenti di product analytics e di sperimentazione usano le stesse regole registrando le chiavi di rollout così che i dashboard raggruppino per prefisso in modo coerente su mobile, web e backend. I bot di code review chiamano l'API con una stringa candidata e incollano l'elenco di issues nel thread di revisione invece di discutere lo stile a gusto. Poiché ogni chiamata riuscita costa il prezzo base pubblicato $0.002 senza token di modello, Lei può convalidare migliaia di nomi in uno script di migrazione senza spese a sorpresa; gli invii vuoti restano gratuiti come errori del client. Allinei la tabella dei prefissi allo stile della Sua organizzazione mappando i verbi interni sull'insieme supportato, oppure avvolga questo endpoint e rifiuti qualsiasi prefisso che la Sua policy vieta anche se la convenzione di base passa.