I’ll Instantly Reject Your Pull Request If You Break These Design Principles
These design principles are non-negotiable. Break them, and your pull request is getting rejected – here’s why they matter.
Code isn’t just about working – it’s about working well.
I’ll Instantly Reject Your Pull Request If You Break These Design Principles
There are few things more soul-crushing than opening a pull request and seeing a spaghetti mess of code that clearly ignores fundamental design principles. It’s not about being a perfectionist – it’s about protecting the long-term health of the codebase.
I’ve been burned too many times by rushed, careless PRs that looked innocent but turned into ticking time bombs. So here’s the deal: if your pull request breaks any of these core design principles, I’ll reject it. No exceptions. And I’ll sleep just fine.
Let’s dive in.
1. Single Responsibility Principle (SRP)
“Do one thing, and do it well.”
I’ve seen classes that try to do everything – fetch data, validate it, transform it, and then email it to your grandma. That’s not clever. That’s chaos.
Each class, function, or module should have one reason to change. When a piece of code tries to juggle multiple responsibilities, it becomes impossible to test, debug, or refactor without breaking something else.
Red Flag in PRs:
• A 500-line class that handles multiple unrelated tasks.
• Utility functions that mix I/O, business logic, and formatting.
What I want instead: Small, focused units that are easy to test and compose.
2. DRY – Don’t Repeat Yourself
“Repetition is the root of all evil… and bugs.”
Copy-pasting blocks of logic is a lazy trap. It might feel faster now, but wait until you have to update that logic in five places – and miss one.
Red Flag in PRs:
• Repeated code snippets doing the same thing in slightly different ways.
• Functions with 90% similarity that could easily be refactored.
What I want instead: Abstract reusable logic. Create helpers. Extract methods. Be smart.
3. YAGNI – You Aren’t Gonna Need It
“If it’s not solving today’s problem, it doesn’t belong in the code.”
Don’t build a system for the 0.01% use case that might happen in two years. Overengineering slows everyone down. It bloats the codebase with unnecessary abstractions and configuration.
Red Flag in PRs:
• Complex configuration layers for features that haven’t even been discussed.
• Premature class hierarchies and plugin architectures.
What I want instead: Just solve the problem at hand. Solve it well. We’ll refactor when the need actually arises.
4. KISS – Keep It Simple, Stupid
“Simple scales. Complex fails.”
Clever code is a liability. I don’t care if you solved a problem using an obscure language feature or a 4-level deep ternary. If it’s not immediately readable, it’s not acceptable.
Red Flag in PRs:
• One-liners that require three minutes to mentally parse.
• Deep nesting, inline lambdas, unnecessary indirection.
What I want instead: Clear, straightforward code. Think junior dev reading your code at 2 AM level of clarity.
5. Open/Closed Principle
“Open for extension, closed for modification.”
If adding a new feature means editing ten files and touching production code, you’ve missed the point. Your design should allow for easy extension without breaking what already works.
Red Flag in PRs:
• Adding a new use case requires changing the core logic.
• Switch/case statements growing uncontrollably.
What I want instead: Use interfaces. Favor composition over inheritance. Keep the system adaptable without being fragile.
6. Consistent Naming and Structure
“Clarity begins with names.”
Naming is everything. If your function is called processData() and it actually makes an API call, validates a JWT, and renders HTML, we have a problem.
Red Flag in PRs:
• Vague function and variable names.
• Inconsistent naming conventions across files.
What I want instead: Precise, intentional naming. Follow existing naming patterns. Make the code self-explanatory.
7. Separation of Concerns
“Each layer has a job. Don’t mix them up.”
Your view logic shouldn’t know how the database works. Your model shouldn’t care about HTTP status codes. Blending responsibilities leads to code that’s tightly coupled and brittle.
Red Flag in PRs:
• SQL queries in frontend components.
• Controllers making business decisions.
What I want instead: Clearly defined boundaries. A well-layered architecture where data, business logic, and presentation stay in their lanes.
8. Failing to Write Tests (or Writing Useless Ones)
“If it’s not tested, it’s broken. You just don’t know it yet.”
Tests are not optional. And no, a test that just asserts 1 == 1 doesn’t count.
Red Flag in PRs:
• No unit/integration tests for new logic.
• Tests that don’t actually cover edge cases or error states.
What I want instead: Meaningful, descriptive tests. Cover the happy path, the sad path, and the weird path.
Final Thoughts
Design principles aren’t abstract theory – they’re survival tools. They keep your codebase sane, maintainable, and scalable. Ignoring them might save you 10 minutes today, but it’ll cost your team 10 hours next sprint.
So yeah, I’ll reject your pull request without hesitation if you violate them.
But here’s the good news: if you follow these principles, I’ll happily approve your PR, probably leave a “nice work!” comment, and maybe even send you a virtual high-five.
Good design isn’t about writing more code. It’s about writing the right code.
Enjoyed this post?
Let me know your biggest pull request pet peeve in the comments – or better yet, share it with someone who needs to read this.
Follow for more software engineering insights, hard truths, and a little bit of tough love.
