[docs] Coding style: document class constants and discourage global/namespaced constants
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 72/100
- Tipo di issue
- Documentazione
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Tranquilla
- Stack tecnologico
- php
- Ambito
- documentation
Direzione di ricerca
Inizia dalla sezione Constants della pagina Moodle Coding Style all’URL collegato, quindi esamina le indicazioni e gli esempi attuali insieme alle indicazioni PSR-1 citate. Il lavoro è completo quando la pagina documenta la denominazione delle costanti di classe, chiarisce che define() non è la forma preferita per il nuovo codice e spiega le indicazioni per le costanti con namespace.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
What is the Moodle feature that needs documenting?
https://moodledev.io/general/development/policies/codingstyle#constants
The Constants section of the Moodle Coding Style currently only describes global constants, and both examples use define(). It says nothing about class constants, even though they are the preferred form in modern Moodle code and are explicitly covered by PSR-1 (and therefore by PSR-12 and PER-3.0, which we defer to where MCS is silent).
This leaves three gaps:
- Developers have no documented guidance on class constant naming, and have to infer it from PSR-1.
- The page implies define() is the normal way to declare a constant in new code.
- Namespaced constants are not mentioned at all, despite being permitted by PHP and appearing in PSR examples. They don't support autoloading, and the PSR examples using PascalCase are a common source of confusion (see MDLSITE-7040).
Is this documentation specific to a Moodle version?
None
Are you able to provide a patch for this?
None
- Lingua principale
- TypeScript
- Stelle
- 74
- Fork
- 652
- Merge medio
- 2g 50m
- PR unite (30g)
- 12
Guida per i contributori
Apri 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 moodle/devdocs
-
bug documentation help wanted needs-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
bug documentation help wanted needs-triage
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 65/100
-
bug documentation good first issue needs-triage
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
-
bug documentation help wanted needs-triage
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
-
documentation good first issue help wanted migration
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
Tutte le issue di moodle/devdocs
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
copse-dev/agent-pane#2953 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
[Bug]: Matrix progress drafts fail with "Matrix runtime not initialized" during tool activity Apertabug clawsweeper:linked-pr-open clawsweeper:needs-live-repro clawsweeper:no-new-fix-pr impact:message-loss issue-rating: 🐚 platinum hermit P2 regression
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
calcite-components needs triage refactor
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
Esri/calcite-design-system#15203 ·