As I’ve been working in git and crafting my commits with rebase
working toward creating pull requests which are easy to read,
review, and comment, I’ve been noticing myself fall into
habits of naming commit messages similarly which contain code to
acheive similar ends. Further, when I struggle to find the correct
words for a commit message, it’s often easier to being with
a familiar word to get things flowing.
Over the past few months, I’ve also had the pleasure of working
with some great developers. As such, I’ve been afforded the
opportunity to review a lot of their code. If there is one thing I recommend
to all developers, from novice to expert, it’s read code.
Your own, your friend’s, strangers, projects you admire, anything you can get
your hands on.
Not only will it enlighten you to how others write code, new coding patterns
and syntax, but it will empower you to be able to figure out how the code you
use works and how to fix it.
As a quick aside, I was able recently to dig into the Ruby source code, even
into the C, to discover exaclty what was happening with Range bracket
operator access on an empty Array. It felt great to be able to see how Ruby
herself was implemented and know exactly why my code worked; to go beyond “well,
it worked in irb so it must be correct.”
The great thing about reviewing pull requests is that I am able to open
discussions with the authors and inquire as to why they made certain decisions
and what their motiviations were for writing certain code. Also, it gave me a
chance to see code which was not polished and final. Thereby, recognizing
anti-patterns and less than best practices.
Coming back to the topic of this post. These anti-patterns and less than best-
practices extend to commit messages as well. Below I’ve listed some of the dos
and don’ts which I have started to use in my everyday committing.
Read on →