Today I offer another one of the code research posts we’ve been doing. If you want more backstory on the series, check out the last post in the series, where I give a brief history. You should also read it if you want to understand both what I mean by functional C# and for details about its impact on codebases at the method level.
Quick editorial note: a couple of people have commented/sent notes asking about p-values. I’ve been eliding those to keep the posts more narrative. But as we’ve expanded the set of variables we capture, we’ve been looking only at dramatically lower p-values. Those cited in this post, for instance, range between 0 and 0.04, with most being less than 0.01.
I’ll summarize the last functional study here, briefly. Last time, I studied about 500 codebases to see what functional-style programming did to methods and types. And the answer was that it made them less object-oriented, but it had surprisingly little influence on clean code statistics, like
- Lines of code per method or type.
- Cyclomatic complexity.
- Parameters per method.
- Method nesting depth.
- Methods per type.
I expected that functional codebases would correlate with a reduction in all of those things. In other words, I figured that functional-style programming would lead to smaller, clearer, more focused, and less complex methods. It didn’t.
Undaunted, I vowed to take a broader look at the effect of functional programming on a wider array of concerns. And I did just that, with the help of my partner who runs the statistical regressions. Continue reading Functional C# Improves Your Design Without Making Your Code Cleaner, Exactly