1144
Approved!
(lemmy.fmhy.ml)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 02 Jul 2023
1144 points (98.3% liked)
Programmer Humor
19594 readers
822 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
That's why PR should be small. It's much better to have multiple PRs than a single big one.
Totally fair to have gigantic PR full of boilerplate code, but generally you can split the boilerplate and your feature in 2 PRs, where only the feature will get a proper review.
All of this obviously depends on the criticality of the system :p
Or split them per commit at the minimum if you don't want to create a separate PR.
That can lead to another problem though, which is that if a developer knows a merge is only part of the whole change, it becomes easy to assume any issues will be handled elsewhere.
How do you improve on this?
1 bigger PRs, but with multiple smaller commits, so reviews can review by commits?
yeah, fair point. it really only works with standard boilerplate code which is simple enough to not have any issue I guess.. in my case working with a NX monorepo, that would be any code created using the generators