LoC Is a Dumb Metric for Functions

Summary

What’s the quickest giveaway that someone’s an amateur developer? When they tell you to break out a function into smaller functions, and the first reason they cite is “it’s over X lines of code.” Yeah, you heard me. This article is targeted at people who are so easily intimidated by long functions that they fail to see deeper issues with them. It’s about people who take a linear function with no repetition or need for reusability, break it out into smaller functions, and think they accomplished something. I’ve written one-liner functions (besides getters and setters). I’ve written one-hundred-liner functions. I’ve written everything in between, and I have no regrets. So let me teach you some things you should’ve been taught a long time ago. Lesson 1: Stop using aesthetic arguments I cringe when developers say “this function just doesn’t look clean” to justify refactoring in lieu of actual reasoning, as if code cleanliness is an aesthetic judgment that only a true connoisseur can determine. Intuition is valuable, but it’s a hint, not the answer. There’s always a deeper reason. You just may not be articulate enough to express it using reasoned arguments. I can help, but… Lesson 2: “Lines Of Code” is the last thing you should think about Referring to LoC to determine function cleanliness is like judging a paragraph of a book by how long it is. If the exact same information can be communicated in fewer lines of code, and if all else is equal, then sure, conciseness is valuable. But all else is rarely equal. While function length can exacerbate cleanliness problems, it’s rarely the root cause. Lesson 3: Cognitive Complexity A superior metric to LoC is CC. A good linter will warn you when your cognitive complexity reaches a certain amount. I try to keep my functions under a CC of 15, but it’s up to you and your team. What matters is that you don’t treat it as gospel. What matters even more is that you try to simplify your function’s logic BEFORE you even think about decom...