undefined

points

[-]

Similarly, I try to follow an “around 400 lines per MR” (violations can exist for test code if something is particularly gnarly).

I’ll build whole features and then break them apart into several MRs that chain off each other.

Everyone who has seen this style has been really grateful for it and finds my code much more readable. I encourage and embody the pattern everywhere I go.

Exception: For mass find/replace or auto-linter changes, that’s all one MR, and is usually pair programmed so the other person can confirm that’s all I did, still easing cognitive load.

by twelve403 hours ago|

prev|

[-]

but then you end up with a clusterfuck of classes?

by t-writescode9 minutes ago|

parent|

[-]

You’d be surprised how often this doesn’t end up happening, especially in languages that are supportive of this style:

Kotlin, Python and Typescript, to name a few. A lot of functions you write are helper functions, wrapper functions, system functions, etc and all 3 languages support making things modules of interconnected concepts, extension functions, etc.

You can make code very readable this way - arguably more readable.

Have you ever had so many tests for a single class that you’ve broken the test class into a package and have a whole file / test class for each big method? Same idea! :)