For those who aren’t familiar with the term, refactoring is the process of rearranging the innards of a body of code without changing its external behavior. This isn’t a discussion about refactoring techniques, though, but instead about how refactoring plays into code reviews.

Continue reading →

Coders have differing opinions about seemingly inconsequential aspects of their work, like code style.

• whether to use spaces or tabs for indentation
• where to introduce blank lines
• how to format comments: end-of-line, single line, block
• whether to comment at all
• which bracket style to use: GNU or 1TBS or Java or Stroustrup or …
• how to order import / include statements
• how long lines may be, and where to break them

As you gain experience (read: get older), you realize that what’s important isn’t which choice is “correct”, but using the same choice consistently across your team’s code. (If you are a lone coder, it’s your world, go nuts!) Establishing a house style makes it easier, mentally, to read over all of the code, regardless of who wrote it.

Continue reading →

In this little series of posts, I’ll describe techniques that you, humble coder, can use to make your code reviews smaller. Why do that? Justifications abound, so I’ll just link you to a couple of good articles.

• Why and how to make smaller pull requests
• The art of small pull requests

In my own writing, I’ll get into the details of how to accomplish the goal of smaller code reviews. I will use git terminology, but the ideas should apply to any version control system where human review is involved.

---

I’ll start off with one of my favorite tricks for forming a small code review, which is what I’ll call here a “no-effect” change.

Suppose that you have a set of changes spread across a ton of files. All of the changes are related to one idea (great!), but there are simply a lot of them. Find a small set of files that could be split into their own review and do so, even if merging them doesn’t change program behavior.

Continue reading →