Why is this code like this?

A practical guide to finding the reason behind any line · Updated 28 September 2026

Every codebase has lines that only make sense if you were in the room: a retry count of 2, a 45-second timeout, a feature flag that should have died years ago. The code tells you what happens. The reason almost never lives in the code itself. It lives in a commit message, a pull request, a review comment, a ticket, or a chat thread. Here is how to dig it out, in the order that finds it fastest.

1. Blame the line, but skip the noise

Plain git blame often lands on a formatting change or a file move. Tell it to look past those:

git blame -w -C -C -L 120,130 src/payments/retry.py

-w ignores whitespace-only changes.
-C -C follows code that was moved or copied from other files.
-L limits the output to the lines you care about.

If a big reformat keeps showing up, list its commit in a .git-blame-ignore-revs file and run git config blame.ignoreRevsFile .git-blame-ignore-revs. GitHub's blame view honours the same file.

2. Follow the line's whole history

Blame shows only the last change. To see every change to a range of lines, including the one that first introduced the odd value:

git log -L 120,130:src/payments/retry.py

If you know the value but not the line, use the pickaxe to find the commit where that string appeared or disappeared:

git log -S "MAX_RETRIES = 2" --oneline

Add --follow when you're tracking a single file that has been renamed.

3. Go from the commit to the pull request

Commit messages are short. The real argument usually happened in the pull request. On GitHub:

gh pr list --search <commit-sha> --state merged

Or open the commit in the browser; GitHub links it to the PR that merged it. With squash merges, the PR number is usually in the commit title, e.g. (#1482).

4. Read the review thread, not just the description

The PR description says what the author intended. The review comments say what was rejected and why. That is usually where you find the sentence you need: "we tried 3 retries and it doubled charges during the outage". Look for resolved threads, because GitHub collapses them by default.

5. Check what the PR points to

The linked ticket (Jira, Linear): the original bug report or requirement.
ADRs and design docs from around the merge date.
Team chat: search for the PR number or the value itself around the merge date.
Incident postmortems: odd limits and timeouts are very often the fix for an outage.

6. When the reason was never written down

Sometimes the trail goes cold. Ask the author if they're still around. Then write the reason down next to the code, as a comment with a link to the PR or incident, so the next person doesn't repeat the search. Before deleting a line nobody can explain, treat it like a fence in a field: find out why it was put there first.

The honest summary: the answer is usually one blame, one log, one PR and one review comment away. It's slow because those four things live in different places, and nobody remembers which one holds the answer.

Doing this automatically

This is the search Enhanciar automates. It reads the history behind your code (commits, pull requests, review comments and docs), answers "why is this like this?" in plain language, and cites the exact file:line and PR it came from. Then it re-reads every cited line and grades each claim as supported, partial, unsupported or unverifiable before you see it, so a citation that doesn't say what the answer claims gets flagged instead of trusted. Your AI coding agents can ask it the same questions over MCP.

Join the waitlist at enhanciar.in →

FAQ

How do I find out why a line of code was written?

Run git blame on the line (with -w -C -C to skip whitespace and moved code), open the commit, then find the pull request that merged it and read the review thread. The commit shows what changed; the PR discussion usually shows why.

How do I find which pull request introduced a commit?

On GitHub run gh pr list --search --state merged, or open the commit page, which links to the PR. For squash merges, the squashed commit message usually contains the PR number.

What if git blame only shows a refactor or formatting commit?

Use git blame --ignore-rev (or a .git-blame-ignore-revs file) to skip it, or git log -L to follow the full history of that line range through every change.

What if the reason was never written down?

Check the ticket linked in the commit or PR, the ADRs or design docs from that period, and team chat around the merge date. If nothing exists, ask the author, then write the reason next to the code so the next person doesn't have to repeat the search.