Skip to content
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.

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

Improve NVDA's coding standards #17666

Merged
merged 8 commits into from
Mar 3, 2025
Merged
Changes from 2 commits
Commits
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
21 changes: 21 additions & 0 deletions projectDocs/dev/codingStandards.md
Original file line number Diff line number Diff line change
Expand Up @@ -115,5 +115,26 @@ Instead use initializer functions.
Docstrings should use [Sphinx format](https://sphinx-rtd-tutorial.readthedocs.io/en/latest/docstrings.html).
Providing type information in docstrings is discouraged, instead use python's type annotations.

Class-level and module-level docstrings should contain a high-level overview of the class/module, optionally with usage examples and references to commonly used methods/functions and attributes.
Document class constructors in `__init__`, not at the top of the class.
Document class attributes in a docstring immediately below the attribute being described.

NVDA formerly used [epytext](https://epydoc.sourceforge.net/manual-epytext.html) syntax for docstrings, which means there is inconsistent syntax used in the NVDA code base.
[#12971](https://github.com/nvaccess/nvda/issues/12971) exists to track converting epytext docstrings to Sphinx.

### Language choices

The NVDA community is large and diverse, and we have a responsibility to make everyone feel welcome in it.
As our [contributor code of conduct](../../CODE_OF_CONDUCT.md) says:

> Communities mirror the societies in which they exist and positive action is essential to counteract the many forms of inequality and abuses of power that exist in society.

The wording choices we make have power, and as a part of our responsibility to be welcoming and inclusive, it is up to us to make sure the way we communicate, including in code, does not negatively impact others.
Consequently, authors should avoid metaphors, euphemisms or other language with layers of meaning or negative history; avoid generalisations about people, cultures or countries; avoid ableist language; and use gender-inclusive terminology.
For example:

* Instead of master/slave, prefer leader/follower, primary/replica, or other terms as appropriate.
* Instead of blacklist and whitelist, prefer blocklist and allowlist.
* Instead of sanity check, prefer confidence check.
* Instead of dummy (value), prefer placeholder.
* When referring to a person of unknown gender (such as in docstrings), use they/them/theirs pronouns.