[snarfy]

## HARD RULE - design scope must always be maintained and no function should ever be longer than XXX lines and no class should have more than Y methods. Create new classes and subclasses and refactor until the criteria are met.

You'd be surprised how readable this makes the code when XXX is about the size of your vertical screen and Y is relatively small.

[t-writescode]

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.

[twelve40]

but then you end up with a clusterfuck of classes?

[t-writescode]

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! :)