Oh my oh my ! I just opened up a stored procedure. I thought it would be ok, after all, it was written by a senior developer in the company, who has proven his worth over and over again.
3 thousand 8 hundred and thirty 4 lines of code. I had to write this out – because it is so ridiculous.
I do not want to read this crap. It’s going to take forever to figure out what this does. I’m tempted to just start rewriting it straight away.
Short functions are important for a number of reasons.
- They are easier to write.
- They are easier to test. I’m not even talking about unit testing. Just good old eyeballing is easier also. And if you want to punish yourself, try to write unit tests for a 3000 line function. It’s a nightmare.
- They are easier to read. This is true not only because they are short – but they force you to give them proper names (or at least to try). So the code ends up reading like a story book.
Once you start to realize that your 3000 line ProcessData() function is a bad idea, breaking it up into smaller functions forces you to think about your code in a totally different manner. If ProcessData is a bad name, ProcessDataPart1, ProcessDataPart2 and ProcessDataPart3 are probably not a good idea either.
And if that’s not a good idea – it means that the functions need to become even smaller – because ProcessData2 does not perform any single action that I can name the function after.
Oops! I did it!
I tried not to say the words Single Responsibility Principle. I did. My bad.
There is an interesting side-effect to enforcing a minimum length on functions. It tends to lead to single responsibility functions.
There are very few things that I cannot achieve in 20 lines or less. Or, more specifically in a few functions where each function is 20 lines or less. Each function ends up doing a single thing well. It’s easy to test. It’s easy to read. And, when the roof caves in on me – it’s relatively easy to fix such a small function.
Oh, and it’s much easier for new developers to understand the code. Most of it is now written in English, not in C# anymore. When you finally find the C# code, it generally does something exceptionally simple. ( Keep in mind that lot’s of simple, little pieces can still create a massive, complex system.)
Find your own niche with this stuff. 20 lines works for me. If memory serves, the Linux kernel team does not accept anything longer than 5 lines. I don’t work on the kernel.
A mentor used to say that if he could see the entire function on the screen at once – it was OK with him. I’m less trusting. You will always find that one developer who changes his font to a 6pt font – just to pass the code review, right?!
What is important is that you are consistent. Simply start breaking complex problems down into many more less complex pieces. You will see the benefits. I promise.
DevOps rule my world
By the way, a nice side effect of enforcing some sort of maximum length rule is that while it can be extremely hard to enforce the Single Responsibility Principle in code, it is really easy to enforce a max length rule in code. And since shorter functions ultimately leads to functions with fewer responsibilities, you are still heading in the right direction.
Don’t tell anyone that I said so….. but, you can even automate the check for function length and fail the automated build if it does not meet the expectation. But be nice and build in a bit of leniency ….