Guidlines for error messages

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

Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:

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.