mirrors/dmd
1
0
Fork 0
mirror of https://github.com/dlang/dmd.git synced 2025-04-26 05:00:16 +03:00
Code Issues Projects Releases Packages Wiki Activity Actions 5

CONTRIBUTING.md: add section on Refactoring

Browse source
This commit is contained in:
Walter Bright 2021-05-31 20:32:55 -07:00
parent 3a23ca4f39
commit cacb0e1587
1 changed files with 23 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

24
CONTRIBUTING.md
View file

@ -53,7 +53,12 @@ Before submitting a PR there are some things you can check which will hopefully
- Ensure newly introduced symbols are documented and that updates to existing symbols are reflected in the documentation.
- Add a link to the PR to the Bugzilla entry.
- Add a link to the PR to the Bugzilla entry (if the dlang-bot failed to do it).
- Confine a PR to addressing one Bugzilla entry, unless multiple entries are different aspects of the same bug.
- If submitting a bug fix PR that does not have a Bugzilla entry, add a Bugzilla entry for it and then submit the PR
that fixes it.
- If your pull request affects the language specifications in any way (i.e. changing the grammar, deprecating a feature, or adding a new one),
a pull request to [the website](https://github.com/dlang/dlang.org) should be submitted in parallel.
@ -70,6 +75,21 @@ For first-time contributors, we suggest looking for issues categorized as [trivi
If you want a hassle-free contribution look for issues categorized as [preapproved](https://issues.dlang.org/buglist.cgi?component=dmd&keywords=preapproved&product=D).
## Refactoring
The purpose of refactoring is to make the code easier to understand. It is not to change the behavior of the
program, add enhancements, or fix bugs.
- Refactorings must come with a rationale as to why it makes the code better.
- Break up larger refactorings into a series of self-contained PRs rather than one gigantic one.
- Significant refactorings that include bug fixes and/or enhancements will be rejected with a
request to submit bug fixes and enhancements as separate PRs. Putting them as separate commits
is not sufficient. Refactorings will be reviewed on their own merits, not conflated with
other changes.
## DMD Best Practices
Here is a shortlist of stylistic issues the core team will expect in
@ -155,6 +175,8 @@ Such functions should not be mutating the data nor issuing error messages.
21. The more constrained the scope of a name is, the shorter it should be.
22. Public declarations in modules should be "above the fold", i.e. first in the file, thus making the API of the module
easily visible when opening the file. Private declarations should follow afterwards.
## The following will not be viewed with favor: