Hacker News new | past | comments | ask | show | jobs | submit login

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.

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...

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

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact