[Question] Why are some configuration keys changed to snake_case while others are still camelCase?
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- yaml
- Ambito
- api, documentation
Direzione di ricerca
Start with the linked configuration.extractor.yaml example and compare its key naming with the v7alpha3 configuration rules. Trace where the example or configuration schema is documented or generated; done means the naming convention and the reason for any mixed keys are made consistent or clearly documented.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Release version
v7.0.0-alpha.3.0.0
Question Details
Since v7alpha3 some configuration keys use snake_case, like named_values, service_policies, version_sets. However many keys still use camelCase, like apimServiceName, displayName, loggerId etc.
Why are some snake_case and others still camelCase? I find this personally super confusing and inconsistent.
For example below the new configuration.extractor.yaml example, why is workspaceName1 camelCase and then further below named_values is snake_case? To me this seems strange to mix naming conventions like this.
workspaces:
- workspaceName1:
apis:
- workspaceApiName1:
operations: []
diagnostics: []
schemas: []
releases:
- workspaceReleaseName1
backends:
- workspaceBackendName1
diagnostics: []
groups: []
loggers:
- workspaceLoggerName1
named_values:
- workspaceNamedValueName1
policy_fragments:
- workspacePolicyFragmentName1
products:
- workspaceProductName1
subscriptions: []
tags:
- workspaceTagName1
version_sets:
- workspaceVersionSetName1
Expected behavior
Either all keys should use camelCase as it previous was or all keys should use snake_case.
Actual behavior
Some keys are camelCase, some are snake_case.
Reproduction Steps
None
- Lingua principale
- C#
- Stelle
- 449
- Fork
- 248
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Azure/apiops
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
-
[BUG] Publisher misses logger dependency in policy XMLForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 70/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 55/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
Tutte le issue di Azure/apiops
Issue simili
-
[i18n] 安装实例完成后的成功提示未正确本地化Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
PCL-Community/PCL-CE#3658 ·
I maintainer di solito rispondono entro 1 giorno
-
Deploy & Patch-issues opprettes ikke: create-pnd-issues.yml har feilet hver uke siden 2025-09-08Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
Altinn/altinn-auth#4359 ·
I maintainer di solito rispondono entro 1 giorno
-
アプリ: チャット 優先: 中 提案
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
yksr-melt/Meltype#243 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
type/automation type/tech-debt
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
High-DPI fixes for release/1.3: editor toolbar icons and Color Picker layout (patch included)Apertano-stack-trace
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
I maintainer di solito rispondono entro 1 giorno