[docs] Coding style: document class constants and discourage global/namespaced constants
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 72/100
- Issue type
- Documentation
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- php
- Domain
- documentation
Research direction
Start with the Constants section of the Moodle Coding Style page at the linked URL, then review its current guidance and examples alongside the referenced PSR-1 guidance. Done means the page documents class constant naming, makes clear that define() is not the preferred form for new code, and explains the guidance for namespaced constants.
Written by the indexing model from the issue text.
Description
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
- Dominant language
- TypeScript
- Stars
- 74
- Forks
- 652
- Avg merge
- 2d 50m
- Merged PRs (30d)
- 12
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from moodle/devdocs
-
bug documentation help wanted needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
bug documentation help wanted needs-triage
Difficulty 1/5 Under an hour Newbie friendliness 65/100
-
bug documentation good first issue needs-triage
Difficulty 1/5 Under an hour Newbie friendliness 72/100
-
bug documentation help wanted needs-triage
Difficulty 1/5 Under an hour Newbie friendliness 72/100
-
documentation good first issue help wanted migration
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Similar issues
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 91/100
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Automattic/studio#4908 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100