Follow These 6 Patterns or I Will Reject Your Pull Request

Get Your PRs Merged Faster! Lessons Learned from Reviewing 1,000+ PRs!

Generated with DALL-E

I’ve reviewed nearly 1,000 PRs while working at a $1.7B GenAI startup, examining code from both junior developers and experienced ex-FAANG engineers.

It’s the small, consistent choices we make every day that make code easier to understand.

By following these guidelines, you’ll not only increase the likelihood of your PR being accepted but also boost your efficiency by merging faster.

Use Early Returns & Align the Happy Path Left

According to Wikipedia:

In the context of software or information modeling, a happy path (sometimes called happy flow) is a default scenario featuring no exceptional or error conditions.

You want your happy path to be left-aligned, meaning it shouldn’t be buried deep within if-else statements. 

Keeping the happy path aligned to the left allows other engineers to quickly skim the code and grasp the function’s purpose more effectively.

One effective way to achieve this is by using early returns.

🛑 Don’t

Don’t

✅ Do

Do

---

Avoid Double negations

🛑 Don’t

Don’t

✅ Do

Do

Keep your code clear by avoiding double negations. A few tips:

1. Use positive variable and function names whenever possible (e.g., isActive instead of isNotActive).

2. Simplify boolean logic by applying De Morgan’s laws.

3. Break complex conditions into smaller, well-named variables or functions if they become too confusing.

Check out the code below, where I use descriptive names like hasRegularAccess for intermediate boolean values:

---

Use Default Params to Avoid Unnecessary Else Statements

🛑 Don’t

Don’t

✅ Do

Do

The key benefits are:

• Default values are immediately clear.

• Less nesting and fewer branches to think about.

---

Have Modular Loop Logic

I’ve seen PRs with massive loop bodies, and if you’re not the code’s owner, it can be difficult to understand what’s going on.

Your goal should be to write skimmable code from top to bottom, with logic tucked away inside well-named functions.

This approach lets first-time readers quickly grasp the overall flow and dive into the functions that matter most to them.

🛑 Don’t

✅ Do

Do

The processUserData function is skimmable. You immediately understand the loop's purpose and know exactly where to look for more details.

A fitting quote:

Functions should do one thing. They should do it well. They should do it only. 

— Robert C. Martin

---

Avoid Booleans in Function Signatures

Avoid using booleans in function signatures. For first-time readers of your code, it’s hard to grasp their meaning.

🛑 Don’t

Don’t

✅ Do

Do

Benefits:

• Improved readability: Function calls become self-documenting

• Extensibility: Adding new roles or options is easier without changing the function signature.

• Clarity: It’s clear what each argument means without needing to check the function definition.

---

Avoid Functions with Side Effects

Make sure your function does exactly what its name suggests — nothing more, nothing less.

Side effects are lies. Your function promises to do one thing, but it also does hidden things that are not obvious from its name. 

— Robert C. Martin

🛑 Don’t

Don’t

✅ Do

Do

---

---

Learn more:

• After Reviewing 500+ React Components, Here’s what I Have Learned

• You’re Decent At JavaScript If You Can Answer These 7 Questions Correctly