Skip to content

Commit

Permalink
Merge branch 'jc/doc-error-message-guidelines' into seen
Browse files Browse the repository at this point in the history
* jc/doc-error-message-guidelines:
  CodingGuidelines: a handful of error message guidelines
  • Loading branch information
gitster committed Nov 28, 2024
2 parents b3ca3e0 + 5ad9fff commit 5a43b77
Showing 1 changed file with 16 additions and 3 deletions.
19 changes: 16 additions & 3 deletions Documentation/CodingGuidelines
Original file line number Diff line number Diff line change
Expand Up @@ -703,16 +703,29 @@ Program Output

Error Messages

- Do not end error messages with a full stop.
- Do not end a single-sentence error message with a full stop.

- Do not capitalize the first word, only because it is the first word
in the message ("unable to open %s", not "Unable to open %s"). But
in the message ("unable to open '%s'", not "Unable to open '%s'"). But
"SHA-3 not supported" is fine, because the reason the first word is
capitalized is not because it is at the beginning of the sentence,
but because the word would be spelled in capital letters even when
it appeared in the middle of the sentence.

- Say what the error is first ("cannot open %s", not "%s: cannot open")
- Say what the error is first ("cannot open '%s'", not "%s: cannot open").

- Enclose the subject of an error inside a pair of single quotes,
e.g. `die(_("unable to open '%s'"), path)`.

- Unless there is a compelling reason not to, error messages from the
Porcelain command should be marked for `_("translation")`.

- Error messages from the plumbing commands are sometimes meant for
machine consumption and should not be marked for `_("translation")`
to keep them 'grep'-able.

- BUG("message") are for communicating the specific error to
developers, and not to be translated.


Externally Visible Names
Expand Down

0 comments on commit 5a43b77

Please sign in to comment.