Feature-Flag-Namen prüfen
Geben Sie einen Flag-Namen ein und sehen Sie sofort, ob er die Konvention erfüllt: enable-checkout-express ist gültig, mit dem Präfix enable und drei kleingeschriebenen Segmenten. Großbuchstaben, gemischte Trennzeichen oder ein einzelnes Wort scheitern mit einer Liste der Gründe. Kostenlos in Ihrem Browser.
- Kostenlos
- Läuft in Ihrem Browser
- Ohne Anmeldung
- Ihre Daten bleiben auf Ihrem Gerät
Im Browser ausführen – kostenlos
Rechenbeispiel
- Name
- enable-checkout-express
- Stil
- kebab
- Präfix
- enable
- Segmente
- enable, checkout, express
- Anzahl der Segmente
- 3
Feature-Flags (auch Toggles, Gates oder Kill Switches genannt) bleiben nur beherrschbar, wenn jeder Name einer gemeinsamen Konvention folgt. Gemischte Großschreibung, camelCase-Reste, willkürliche Akronyme und Flags ohne Verb- oder Bereichspräfix erschweren die Suche, zerbrechen Dashboards und verursachen Kollisionen zwischen Teams. Konventionsverstöße liefern ein strukturiertes Erfolgspayload mit valid false und einer geordneten Issues-Liste, damit die Continuous Integration den Build mit klarem Bericht abbrechen kann.
Was die Namenskonvention verlangt
Ein Feature-Flag-Name unter dieser Konvention ist ein kurzer Maschinenidentifikator, kein freier Fließtext. Drittens muss der Name in mindestens zwei nicht leere Segmente zerfallen, damit ein einzelnes Wort wie checkout nie als Flag ausgeliefert wird; Teams brauchen ein Präfix plus einen beschreibenden Rumpf.
Viertens muss das erste Segment ein bekanntes beschreibendes Präfix aus gängigen Katalogen sein: enable, disable, show, hide, allow, deny, use, is, has, can, feature, ff, exp, experiment, rollout, beta, alpha, new, legacy, dark, light, ops, ui, api, web, mobile, backend, frontend, gate, toggle, flag, release, kill, killswitch, perm oder temp. Fünftens ist die Länge auf vierundsechzig Zeichen begrenzt, damit Konfigurationsspeicher, Umgebungsvariablen und URL-Query-Parameter freundlich bleiben. Führende, nachgestellte oder verdoppelte Trenner werden abgelehnt, damit generierter Code und Regex-Filter einfach bleiben.
Eingabevertrag, Antwortform und Fehlerverhalten
Der Beispielwert enable-checkout-express ist ein gültiges kebab-case-Flag mit dem Präfix enable. Erfüllt der Name jede Regel, ist valid true, issues ein leeres Array und style kebab oder snake. Zahlen werden zu Strings; Objekte und Arrays werden abgelehnt.
Weil die Implementierung reines Parse der Stufe A ist, sind Ergebnisse runtime-stabil ohne Netz und ohne Zeitstempel.
Wo die Validierung von Flag-Namen ihren Nutzen hat
Plattform- und Developer-Experience-Teams hängen diese Prüfung in Scaffolding-Generatoren, damit neue Flags nicht ohne Präfix und Trennzeichenstil landen. Continuous-Integration-Jobs scannen Pull Requests, die Flag-Kataloge oder Beispiel-Umgebungsdateien berühren, und lassen den Build scheitern, wenn ein Name Betreiber sechs Monate später verwirren würde. Produktanalytik und Experiment-Werkzeuge nutzen dieselben Regeln beim Registrieren von Rollout-Schlüsseln, damit Dashboards konsistent nach Präfix über mobile, web und backend gruppieren.
Halten Sie die Präfixtabelle am Hausstil Ihrer Organisation ausgerichtet, indem Sie interne Verben auf die unterstützte Menge abbilden, oder kapseln Sie diesen Endpunkt und lehnen Sie jedes Präfix ab, das Ihre Richtlinie verbietet, selbst wenn die Basiskonvention besteht.
Anwendungsfälle
Migrations- und Aufräumskripte
Prüfen Sie veraltete camelCase- oder UPPER_SNAKE-Flags stapelweise und geben Sie eine maschinenlesbare Issues-Liste für jeden Umbenennungskandidaten aus.
Häufige Fragen
Was passiert, wenn der Name leer ist?
Leere oder nur aus Leerzeichen bestehende Namen können nicht gegen die Konvention geprüft werden.
Welche beschreibenden Präfixe sind erlaubt?
Gängige Katalogpräfixe wie enable, disable, show, hide, feature, ff, exp, experiment, rollout, beta, api, ui, gate, toggle, release, kill und ähnliche Bereichs- oder Intentionsmarker, die der Prüfer auflistet.
Darf ich Bindestriche und Unterstriche in einem Namen mischen?
Nein. Ein Name verwendet durchgehend nur eine Art von Trennzeichen: Bindestriche oder Unterstriche, nie beide. Eine Mischung ist ein klarer Fehler, genau wie ein Großbuchstabe, ein Leerzeichen, ein Schrägstrich oder ein Satzzeichen.
Warum wird ein einzelnes Wort wie checkout abgelehnt?
Die Konvention verlangt mindestens zwei nicht leere Segmente: ein bekanntes Präfix wie enable oder rollout und einen beschreibenden Teil. Ein einzelnes Wort verrät weder die Art des Schalters noch den Produktbereich, zu dem er gehört.
Wie lang darf ein Feature-Flag-Name sein?
Höchstens 64 Zeichen. So bleiben Namen in Konfigurationsdateien, Umgebungsvariablen und Webadressen handlich. Trennzeichen am Anfang, am Ende oder doppelt hintereinander werden ebenfalls abgelehnt.
Verwandte Tools
Für Entwickler — API-Zugang
Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.
Endpunkt
Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.
Aufruf aus Ihrem Stack
curl -X POST https://api.kit.forhosting.com/dev/feature-flag-name-validate \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"name":"enable-checkout-express"}'const res = await fetch("https://api.kit.forhosting.com/dev/feature-flag-name-validate", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"name": "enable-checkout-express"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/feature-flag-name-validate",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"name": "enable-checkout-express"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/feature-flag-name-validate", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"name":"enable-checkout-express"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"name":"enable-checkout-express"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/feature-flag-name-validate", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Beispiel-Anfrage
{
"name": "enable-checkout-express"
}Beispiel-Antwort
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.feature_flag_name_validate",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.
Preis
Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.
Fehler
| HTTP | Code | Bedeutung |
|---|---|---|
401 | unauthorized | Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer). |
402 | insufficient_balance | Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht. |
404 | unknown_type | Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog. |
429 | rate_limited | Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt. |
Technische Hinweise
Diese Fähigkeit prüft einen Kandidatennamen gegen ein praxisnahes Industriemuster: nicht leer, durchgängig klein, entweder hypheniertes kebab-case oder snake_case (nie beide Trenner in einer Zeichenkette), mindestens zwei Segmente, beschreibendes Präfix wie enable, feature, ff, rollout oder beta, höchstens vierundsechzig Zeichen und keine Rand- oder Doppeltrenner. Leere Eingabe schlägt mit invalid_input fehl und wird nicht abgerechnet.
Was die Namenskonvention verlangt
Erstens darf er nicht leer oder nur aus Leerzeichen bestehen: ein leerer Name wird sofort als invalid_input abgelehnt, weil es nichts Nützliches zu bewerten gibt. Zweitens muss jedes Zeichen ein Kleinbuchstabe im ASCII-Bereich, eine Ziffer und genau ein Trennzeichenstil sein—Bindestriche für kebab-case oder Unterstriche für snake_case. Das Mischen von Bindestrichen und Unterstrichen im selben Namen ist ein harter Fehler, ebenso Großbuchstaben, Leerzeichen, Schrägstriche oder andere Interpunktion. Zusammen passen diese Regeln sauber zu LaunchDarkly-artigen Schlüsseln, Unleash-Toggles und den meisten internen JSON- oder YAML-Flag-Dateien, ohne einen herstellerspezifischen Dialekt zu erfinden.
Eingabevertrag, Antwortform und Fehlerverhalten
Bei Erfolg enthält die Antwort immer valid (boolesch), den getrimmten name, style (kebab, snake oder null, wenn das Muster nicht klassifiziert wurde), prefix (erstes Segment oder null), segments als geordnetes String-Array, segment_count, has_descriptive_prefix, issues als stabile geordnete Liste maschinenlesbarer Codes und einen kurzen convention-Satz für die Oberfläche. Ist der Name vorhanden, bricht aber die Konvention, ist valid false und issues listet Codes wie not_lowercase, mixed_separators, missing_descriptive_prefix, too_few_segments, invalid_characters, consecutive_separators, leading_or_trailing_separator, too_long, missing_separator_segments oder invalid_pattern—ohne Exception—damit Linter und Pull-Request-Bots alle Probleme auf einmal ausgeben. Nur leere, fehlende oder nicht-stringige Namen werfen invalid_input; diese Fehler verbrauchen kein Prepaid-Guthaben.
Wo die Validierung von Flag-Namen ihren Nutzen hat
Code-Review-Bots rufen die API mit einer Kandidatenzeichenkette auf und fügen die Issues-Liste in den Review-Thread ein, statt Stil nach Geschmack zu streiten. Weil jeder erfolgreiche Aufruf den veröffentlichten Basispreis $0.002 ohne Modell-Tokens kostet, können Sie Tausende Namen in einem Migrationsskript prüfen ohne Überraschungsausgaben; leere Einsendungen bleiben als Clientfehler kostenlos.
Integrationsbeispiele
CI-Lint für Flag-Kataloge
Scannen Sie YAML- oder JSON-Flag-Dateien in Pull Requests und lassen Sie den Build scheitern, wenn ein Name leer ist, gemischte Großschreibung hat oder ein beschreibendes Präfix fehlt.
Scaffolding und CLI-Generatoren
Prüfen Sie den Namen, den ein Entwickler eingibt, bevor enable-foo-bar in Konfiguration, SDK-Stubs oder Feature-Toggle-Dashboards geschrieben wird.
Technische Fragen
Was ist ein gültiger Feature-Flag-Name?
Eine nicht leere Kleinbuchstaben-Zeichenkette in kebab-case oder snake_case, mindestens zwei Segmente, erstes Segment ein beschreibendes Präfix (zum Beispiel enable, feature oder ff), maximal 64 Zeichen, keine gemischten Trenner.
Werden camelCase- oder PascalCase-Namen akzeptiert?
Nein. Großbuchstaben erzeugen not_lowercase in der Issues-Liste und valid ist false. Wandeln Sie zuerst in kebab-case oder snake_case um.
Was kostet der Feature-Flag-Namenprüfer?
Das Browser-Werkzeug ist kostenlos. API-Anfragen nutzen vorausbezahltes KIT-Guthaben zu $0.002 pro erfolgreichem Aufruf; ungültige leere Eingabe wird nicht abgerechnet.