Skip to content

docs: options representation in new APIs #10502

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
MarkoMin wants to merge 1 commit into
base: master
Choose a base branch
from
+6 −0
Open

docs: options representation in new APIs #10502

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -101,6 +101,12 @@ two years later why a particular feature can easily find out. It does no harm to
the same information in the pull request (if the pull request consists of a single commit,
the commit message will be added to the pull request automatically).

* If your pull requests introduce new modules and/or public functions, make sure to follow the rules
about representation of "options":
1. Never use a record for public APIs, because records require an include file, and if elements are added to a record, all code using it must be recompiled.
2. Use a map for options unless a map will not work for some reason (e.g. order is important) or unless the modified module already uses lists (for consistency).
3. If a map doesn't work, use a list.

* With few exceptions, it is mandatory to write a new test case that tests the feature.
The test case is needed to ensure that the features does not stop working in the future.

Expand Down
Loading