Guidlines for error messages

Guidlines for error messages

[Kaartic Sivaraam]

Hello all,

On reading the CodingGuidelines, I saw a section that specifies rules
about the structure and formatting of error messages. I have reproduced
it below,


    Error Messages

     - Do not end error messages with a full stop.

     - Do not capitalize ("unable to open %s", not "Unable to open %s")

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


Having used git all these days, I have seen error messages that do seem
to be violating the above guidelines (at least the first 2 points). A
few are,


    Aborting commit due to empty commit message.


    fatal: There is no merge to abort (MERGE_HEAD missing).


    fatal: You have not concluded your merge (MERGE_HEAD exists).
    Please, commit your changes before you merge.


    error: Empty commit message.
    Not committing merge; use 'git commit' to complete the merge.


    error: pathspec 'hell' did not match any file(s) known to git.


    fatal: Not a valid object name foo


    fatal: ambiguous argument 'foo..bar': unknown revision or path not in the working tree.
    Use '--' to separate paths from revisions, like this:
    'git <command> [<revision>...] -- [<file>...]'


A few that do seem to be following the guideline are

    fatal: could not read log file 'imaginary_file': No such file or directory

    fatal: no input file given for in-place editing



    That makes me wonder, has the guideline changed ?
    Is this something that must be fixed ?
    Am I missing something ?

    -- 
    Kaartic

Re: Guidlines for error messages

[Junio C Hamano]

Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:

> On reading the CodingGuidelines, I saw a section that specifies rules
> about the structure ...
> ...
>     That makes me wonder, has the guideline changed ?
>     Is this something that must be fixed ?
>     Am I missing something ?

This applies not just to the message format but with ANY guideline
we have around here.

As we did not have perfect foresight when we started the project,
the guidelines grew out of the best practice we learned over time.
We try to catch violations for new code during the review process,
so that we won't add violators, but we do _not_ actively hunt for
existing violators and change them _only_ to fix them, which is
unneeded code churn.  Instead, over time as people notice, most
often while doing a real work in the vicinity of the code that has
violations, we fix them as preparatory clean-up patches before the
real work happens.