#engineering #implementation

idea

Commit messages are used at multiple steps of the development process: when reviewing code[1], when preparing a deployment or assembling a release, understanding context when reading code, when diagnozing a problem, or to help navigate the history easily. They need to be helpful.

Good commit messages follow simple rules[2] to standardize and make them useful: use imperative and less than 50 chars for the subject, add a body if necessary separated by an empty line which explain what and why rather than how.

Example:

Simplify serialize.h's exception handling

Remove the 'state' and 'exceptmask' from serialize.h's stream implementations, as well as related methods.

As exceptmask always included 'failbit', and setstate was always called with bits = failbit, all it did was immediately raise an exception. Get rid of those variables, and replace the setstate with direct exception throwing (which also removes some dead code).

As a result, good() is never reached after a failure (there are only 2 calls, one of which is in tests), and can just be replaced by !eof().

fail(), clear(n) and exceptions() are just never called. Delete them.

links

[1]: Code reviews

references

[2]: Chris Beams / How to Write a Git Commit Message

The seven rules of a great Git commit message:

  1. Separate subject from body with a blank line
  2. Limit the subject line to 50 characters
  3. Capitalize the subject line
  4. Do not end the subject line with a period
  5. Use the imperative mood in the subject line
  6. Wrap the body at 72 characters
  7. Use the body to explain what and why vs. how