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
references
[2]: Chris Beams / How to Write a Git Commit Message
The seven rules of a great Git commit message:
- Separate subject from body with a blank line
- Limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- Use the body to explain what and why vs. how