Hacker News Reader

Comment by azeirah | Hacker News Reader

I typically find it very difficult to understand complex functions, (100+ lines of code, ~3 or more nesting levels deep) and even simpler complex functions (mixing 2-3 concepts into a 15 line function).

I've only just started doing TDD the "Growing Object Oriented Software guided by tests" way, and I find it incredibly helpful that each and every class does just _one_ thing, even splitting up those 15 line functions into two or three separate classes implementing an interface -- single responsibility -- helps me a lot in reasoning about the code.

I _have_ experienced the dependencies issue myself already though, it's very annoying to click on a method in my IDE, and then get shown the interface definition of that particular method. I'll then have to trace my way through a couple of files to find the dependency, very annoying.

View on HN

This is widely believed and repeated, but empirical evidence actually runs the other way: according to studies cited in the book Code Complete, functions in the range of 100 to 150 LOC are more maintainable than shorter ones.

https://news.ycombinator.com/item?id=6229801

https://news.ycombinator.com/item?id=3876434

https://hn.algolia.com/?query=by:cpeterso%20%22code%20comple...

At the end of the day, a simple measure like LOC can never capture readability, good or bad, and you get eaten by Goodhart's Law if you focus too much on it.

https://en.wikipedia.org/wiki/Goodhart%27s_law

Oh, save us from the scenes,

Where the end becomes the means,

And the forest gets so lost among the trees;

When polishing the source,

Blunts all our creative force,

And procedure kills the genius it claims it frees.

No one would argue otherwise. Indeed, you can trivially take any readable function and transform it into an unreadable one of exactly the same length. But this doesn't seem like a valid reason to dismiss specific findings of specific studies. Don't you think it's interesting that such research as we have contradicts the most often-repeated claim about this aspect of programming?

I don't know. I've learned over the years that there is always a study confirming or contradicting whatever point you want to make. "Beware The Man Of One Study".

I say that without even looking at those studies, which is perhaps unfair. But there are So Many Studies...

My personal experience is that when I was exposed to shorter simple and (so important!) well named functions, my work became so much better. And that is now the school I subscribe to.

That's not - at all - to say you can't also find very good practices doing different things. But that's not where I found it.

Still, one study is still an important piece of evidence to consider when all you had before is no studies and a gut feeling.

My personal experience differs from yours somewhat. I believe it's not the length or the number of methods that matter, but what language (i.e. abstraction) they create. You try to subdivide the function into functions that are natural fit for the task being done, but no further. If you still end up with a long block of code - as you very well might - consider comments instead. A comment telling what the next block of code will do is kind of like inlined function, except you don't have to jump around in file, you don't lose the context. Much easier to read.

I used to write code where essentially every piece of code longer than 3-5 lines got broken out into its own private function. The amount of jumping I had to do when reading the code, and the amount of work maintaining and de-duplicating small private functions, was overwhelming.

is anybody still counting states ? or use https://en.wikipedia.org/wiki/Cyclomatic_complexity ?

We may not be that different.

When I was shown that you can break out a function that's only used once, just in order to name it (2005, or so), it was one of the greatest revelations in my career.

It also serves as a way to tell you what that code does, without you having to know details of how it does it, until the rare day when it's important.

But I only do it when that code is genuinely hard to follow, not because my function is "over 10 lines, and that's our policy".

agumonkey's mention of cyclomatic complexity in a parallel comment made me remember yet another realization wrt. breaking functions out: if you work with languages without local functions and start breaking your large function into smaller functions or private methods, you run into a readability/maintenance problem. The next time you open the file and start reading through all the little helper functions, you start wondering - who uses which one? How many places use any one of them?

With IDE support answering the question for a single function is just a matter of a key combination, but that still adds friction when reading. I found that friction particularly annoying, and a file with lots of small helper functions tend to be overwhelming for me to read (it's one reason I like languages with local functions). Whereas if you didn't break the code out, and only maybe jotted a comment inline, you can look at it and know it's used only in this one place.

Sure, there are both costs and benefits to this, which is why you should only do it when the benefits clearly are bigger than the costs.

Not every time your function line count is > 10, as I heard from some crazy company a friend worked for...

I prefer to put the broken out function(s) immediately below the main one for a logical reading experience: Overview first, details below if needed.

Comments are of course good when they are current and correct. But they rarely stay that way for long...

Code complete speaks about subroutines if I understood correctly. I think that in functions, or even objects, the results would be very different. I usually find the shortest functions more powerful and clear. For example the pipe operator in F# that is nothing more than:

    let (|>) f g = g f

While it has huge benefits in the overall readability of the language.

> I typically find it very difficult to understand complex functions

It seems to me like "complex" and "ability to understand" mean the same thing, so this phrase doesn't have much meaning.

It's difficult to define "ability to understand" / "complex" without using either of those words in the definition. For example, you mention lines of code, nesting and multiple concepts.

I tend to agree with your examples, however not necessarily the lines of code. I've seen single large functions that represent an algorithm in a way that's easier to understand than the implementation that breaks it up into tens of little functions. It made liberal use of comments to explain each section of code in the function. I believe its advantage was that when reading, you could simply scroll down the function line by line rather than having to jump all over the file.

Sure, all I mean is that I get frustrated and lose unnecessarily much time being distracted by keeping a model of how the function works and how variables interact in my head. I have ADHD so my working memory isn't fantastic for these kinds of functions.

I suppose you could take my definition of complexity to be approximate to cyclomatic complexity

Local functions are also really handy when you want to break up a large function into smaller pieces but keep them localized.

Yeah, but I would say it depends on context, clarity is very context dependent. Do what makes the code easiest to read taking into account that human limitations.

Sometimes splitting out code makes sense by making the underlying structure clearer, sometimes it makes it bothersome to find the actual important details. For instance, logic that filters what jobs to run based on conditions, it might make sense to abstract the logic for the conditions into one class per condition, to make the filtering logic clearer.

> Sometimes splitting out code makes sense by making the underlying structure clearer, sometimes it makes it bothersome to find the actual important details.

Yeah, that seems to be something I'll have to spend some time learning about. Right now I'm just mindlessly splitting off everything, and it kind of works, but it's annoying to navigate all over the place just to find some detail somewhere

> it's very annoying to click on a method in my IDE, and then get shown the interface definition of that particular method. I'll then have to trace my way through a couple of files to find the dependency, very annoying.

The IDE should be able to show you the implementations. When using Java and Eclipse for example, you just hold Ctrl and hover with the mouse over a method call. In the appearing dialogue you can then select "Go to implementation" instead of "Go to definition" (or similar) and Eclipse searches for and then shows you all classes that contain an override for that method and then you can click on one of them to view that specific overriding method.

I have a theory about why this functional atomization has become so popular: small design topics (functions, classes) are easy to talk about so the various wannabe OOP gurus like Robert Martin keep talking about them the most, becoming more and more extreme to the point that we end up with hundreds of one line functions which can only really be put together in one way so that they fulfill the arbitrary criteria of reading like prose.

This is an excellent example of local optimizations - i.e. local design optimizations - which end up harming the overall design and maintainability. You've discovered this yourself, but still cling to this dogma of tiny functions.

I made it clear that there are upsides. It's a tradeoff, not "gurus bad".

Reply on news.ycombinator.com