Keep PRs Under 300 Lines of Code
I have always firmly believed in the importance of writing clean, efficient, and well-organized code.
There are many techniques for writing clean code but keeping Pull Requests (PRs) under 300 lines of code has always been one of the easiest ways to improve code quality and developer experience.
In this article, I will explain why I think limiting the size of PRs has become an indispensable part of my software development workflow.
Being close to 300 isn't a target either, but a metaphorical limit to say - MAKE SMALLER PRs!
The smaller, the better...
Easier Code Reviews
Smaller PRs are easier to understand, allowing reviewers to quickly grasp the purpose of the changes and provide valuable feedback.
In contrast, lengthy PRs can be overwhelming and may discourage the reviewers from conducting a thorough analysis.
And if something looks like it will take a long time to review, it's challenging to get people to stop what they are working on to review your code.
Be kind to your peers and respect their time by making it easy to review your code!
If you have been involved in code reviews, I know you have pushed off reviewing a mega PR because of the sheer amount of time it would take to give it a review.
Or what's even more common is just hitting "approve" to get it off your desk without really knowing if it's good code. And that's where a lot of technical debt starts slipping into our applications.
Improved Planning and Flexibility
The constraints of limiting my PRs to under 300 lines of code force me to break down complex tasks into much smaller, more manageable chunks, ultimately leading to cleaner and more modular code.
Taking each task in isolation, I can focus on creating a solution to a problem without getting bogged down by the complexities of a larger system.
This planning has also made me a more flexible developer. By breaking tasks into smaller chunks, I am better equipped to pivot when priorities change, or new requirements emerge.
Since you deliver code more frequently, it gives you more opportunities to pause and evaluate solutions.
This ability to adapt quickly is a valuable skill in the fast-paced world of software development, where project requirements can change instantly.
Less Bugs
By writing less code, you shouldn't be shocked that you will get fewer bugs 🤯.
But there are two main reasons.
Focusing on smaller isolated solutions makes it much easier to test and confirm that all the behavior is as expected. In contrast, if you have several tasks in a single PR, it's really easy to miss something or have another task introduce bugs to another part of your code. And as the lines of code increase, it is harder to do the mental gymnastics required to think of all the situations you might have.
Giving your team digestible PRs gives them a real opportunity to see something you may have missed.
Reduced Risk of Merge Conflicts
Early in my career, merge conflicts terrified me, and to be honest, when there are a lot of them, not much has changed. 😂
Smaller PRs mean fewer lines of code are being modified simultaneously, decreasing the likelihood of conflicts arising.
In cases where conflicts do occur, resolving them becomes a less daunting task as there are fewer changes to sift through.
If you have any influence over your teams, I would ask you to try and push your team to have this soft limit on their PRs, and you will watch everyone's experience improve.
Like all new things, it's difficult to start, but once you get used to the process of delivering small incremental changes, you'll never go back.
There is something satisfying about consistently delivering and merging code daily, which is much easier to achieve when you make things smaller.
Follow me on Twitter or connect on LinkedIn.
🚨 Want to make friends and learn from peers? You can join our free web developer community here. 🎉
