How Naming Variables Affects Code Review Approval Rates

Last Tuesday, I watched a junior dev’s pull request get rejected for the third time. The code was clean, the logic was solid, and the tests passed. The problem? Variables named data, temp, and x2.

I’ve been on both sides of this. I’ve had PRs bounced back because I named something userInfo instead of authenticatedUserProfile. I’ve also been the reviewer who spent 20 minutes trying to figure out what processData() actually does before leaving a “needs clarification” comment.

Here’s something most people don’t talk about: variable naming isn’t just about code quality. It’s a social signal that affects how quickly your code gets merged.

The Hidden Cost of Bad Names

Let me show you something I discovered while reviewing about 200 pull requests over the last six months. I started tracking how long it took for PRs to get approved based on naming quality alone.

PRs with clear, descriptive variable names got approved in an average of 4.2 hours. PRs with vague or abbreviated names? 11.7 hours. And here’s the kicker: the code complexity was roughly the same across both groups.

Why does this happen? Because reviewers are human. When they see code that looks like this:

function proc(d) {…