Skip to content

docs: add ValueError message wording conventions to CODING_STANDARDS #21761

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
jorgsowa wants to merge 1 commit into
base: master
Choose a base branch
from
+10 −0
Open

docs: add ValueError message wording conventions to CODING_STANDARDS #21761

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
10 changes: 10 additions & 0 deletions CODING_STANDARDS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -79,6 +79,16 @@ rewritten to comply with these rules.
return value for functions that perform some operation that may
succeed or fail.

1. When throwing a `ValueError` or emitting a warning, use consistent
phrasing for error messages. Common patterns are:

* Type errors: `must be of type int` (use the type name, not e.g. `must be an integer`)
* Range/boundary: `must be between X and Y` / `must be greater than [or equal to] X` / `must be less than X` / `must be finite`
* String constraints: `must not contain any null bytes` / `must not be empty` / `must be a single character`
* Valid value: `must be a valid X` (e.g. `must be a valid encoding`, `must be a valid calendar ID`)
* Enum-like: `must be one of X, Y, or Z`
* Structural: `must have X` / `must have key X` / `must have N elements`

## User functions/methods naming conventions

1. Function names for user-level functions should be enclosed with in the
Expand Down