Hacker News Reader

Comment by moonshinefe | Hacker News Reader

Has anyone seen production code with <=10 lines of code per function before? I've honestly never seen it, and I think at that point the code becomes harder to read because you're tracing through function definitions to decipher what a single function should do.

I usually notice functions get hard to read when they hit 80 lines or so long (generalization, of course), and try to keep mine under say 50 unless it's one of a few core functions in an application.

Interested in hearing others' experiences.

View on HN

> Has anyone seen production code with <=10 lines of code per function before?

I have seen code where a function was shorter than 10 lines. ;-) In that same code base, I have seen a function that was ~750 lines. And for that particular function, it actually made sense. It involved a lot of local state, and breaking it up would have involved passing lots of parameters to the new, shorter functions. (The average function in that code base was around 50-60 lines, I guess.)

Using a fixed number, like "10 lines" seems arbitrary to me. Sometimes it makes sense, sometimes it does not. It also ignores other factors, such as comments. Or readability. Sometimes, I 100+-line function can be marvelously clear, other times, a 5-liner can be so dense it makes my eyes bleed.

I have grown wary of "Always do this"/"Never do that"-advice.

"Try to keep your functions short. If they grow long, look if it makes sense to break them up into multiple shorter functions" is sound advice. But to do so without questioning or thinking is problematic.

Agreed.

> I have seen a function that was ~750 lines. And for that particular function, it actually made sense. It involved a lot of local state, and breaking it up would have involved passing lots of parameters to the new, shorter functions

If I was refactoring it, and 750 lines is a massive red flag that it is in need of refactoring; then the local state indicates that it becomes not a function or a bunch of functions, but a class with state and private methods. Is that hard to spot?

I actually missed that one part of his response when I agreed in reply. 750 lines is definitely a red flag for refactoring.

Well, I agree that 750-ish lines is a bit extreme, but that function was a Win32-message handler. It basically consisted of a huge switch statement that figured out what the message was, did a little parameter mangling and then called a function that did the actual work.

So while that function was very, very long, it was relatively simple to understand and did not contain a lot of logic. Also, the fact that it was a huge switch would have made breaking it up slightly non-trivial.

Yes, the "big switch" is the canonical example of something that's hard(er) to break down and easy(er) to read as 1 function.

Though I would still try things like :

- making each case in the switch as small as possible, preferably a 1-liner.

- making a separate object that does the "parameter mangling".

- grouping all the bits of state into an object to hold the "message loop state".

- Or most radically but best: these "map", "lookup", "strategy" style patterns that reduce it to a table of (message id, handler fn) pairs http://stackoverflow.com/a/126453

It was years ago that I worked at that company. Unfortunately, things like refactoring weren't very big there, and the other developers - who were, I should emphasize, really nice guys! - were not exactly open to change.

When I was hired there, that application had been in development for ~15 years, and a lot of what I did was maintenance. So making coming in as the new guy, then starting to change things, I had to tread rather carefully.

FWIW, I got each of the three developers to individually admit to me that if we had the time and the money, we would basically throw the old code out and rewrite it from scratch, using the lessons they had learnt since. But time and money being what they were, that was not likely to happen. (I was really proud I got them to admit that, though - one of the other developers was very defensive of his work, and getting him to admit that was quite an achievement; I actually gained some valuable people skills in doing so.)

I was glad, though, that the code was relatively readable and organized in a sane manner. There was some cruft that had accumulated over the years, but overall it was surprisingly sane. That was one of the first times I had to read somebody else's code, and it was good code for that purpose - sparsely commented, yet very clear.

Also, keep in mind that this was C. Different languages offer different ways of decomposing / structuring code.

My impression is that it is somewhat influence by the programming language. Code I've written have often needed so many variables to do its job that it is very hard to split out small functions. But when you can use closures and higher order function easily, I find it easier to keep the size of functions down.

But I prefer Linux take on function size:

> The maximum length of a function is inversely proportional to the complexity and indentation level of that function. So, if you have a conceptually simple function that is just one long (but simple) case-statement, where you have to do lots of small things for a lot of different cases, it's OK to have a longer function.

You might want to see this: https://www.youtube.com/watch?v=npOGOmkxuio Not really about production code, but still, some food for thought. Also this: https://www.youtube.com/watch?v=8bZh5LMaSmE

She seems like a great speaker, will bookmark for later. TY.

Her book "Practical Object-Oriented Design in Ruby"[1] is also quite good

[1]: http://www.poodr.com/

Those are really excellent. I don't work in Ruby, but her explanations of OO design and refactoring are among the clearest, and most concise, I've ever seen. I'm gonna be watching her talks for the next couple hours, I suspect.

Maybe people just don't handle errors? Most of my functions are less than 10 lines, but then you add the error handling code, and it becomes 30 lines.

Also, it strongly depends on the code you are writing. Things like reading/writing data often end up as pretty long functions, while glue code between model and view is usually just a couple of lines.

My general rule of thumb is that a function should be small enough to be entirely visible on screen without having to scroll. It's dependent on screen resolution & font size of course, but I find that having to scroll down adds some cognitive overhead to understanding the whole of a function.

Following this line of thought I've become a lot more precious about vertical whitespace & I've adopted BSD style curly braces.

Fair enough. I always found horizontal scrolling more difficult than vertical though.

But, for instance, the Python PEP8 spec saying 80 characters max, I think is kind of ridiculous these days. Who is programming on their phone, tablet, or 90s computer that can't handle 120 characters these days?

Edit: I just mention 120 as PyCharm's PEP8 linter 'erroneously' checks that max rather than 80

Agreed horizontal scrolling is equally disturbing. We do live in an age of wide-screen monitors though so I find vertical whitespace more precious. I would go as far as saying that 160 horizontal chars is a more sensible guide these days.

In my personal experience, the small function thing can drive a maintainer bananas.

When trying to understand code I haven't written, I have had the experience that trying to trace logic and debug through a bunch of little functions is more cognitive overhead than just seeing everything that happens within one larger function.

I get the idea that small functions are supposed to be wonderful, and clear, if everything is named really well and everything works as the name implies.

But for me the downside is it ends up feeling like detective work. I have to jump around and remind myself exactly how each little function works just to figure out what exactly is happening.

My dream IDE would let me see "expand" every function call ... like with little dropdown arrows .. so I could see it as if it were inline, and could trace execution linearly in one solid block.

> Has anyone seen production code with <=10 lines of code per function before?

It depends on the language. In Node.js code, it's not uncommon to not only see production code that follows this rule, but also puts no more than 1 or 2 functions in each file. Once you get used to it, and as long as you're quick with your editor/IDE's open shortcuts, I've found it a pretty nice way to organize code.

I personally find C code hard to follow sometimes, not because I don't understand C (I have more experience with C than I do JavaScript, if you count years), but because C tends to feature multiple functions per file, each with hundreds of lines of code per function. At least for me, that's hard to follow, and I hate having to move hundreds of lines up and down a file, even using Vim shortcuts.

I used to stick religiously to <=15, in C#. This was detrimental to understanding only twice, and a fairly small issue even then. Not a ridiculous standard for interns who don't have an excellent refactor-sense yet, so I didn't begrudge it back then.

But in sticking to that standard, what was the effort balance between improving understanding vs. busywork to meet the guideline?

Edit: Huh? Why a downvote?

For a rule made with the goal of improving understanding, it's great that the rule is not actively detrimental to understanding.

But we still need to know how often it actually succeeds vs. having marginal effect.

We also need to know what it costs in terms of labor.

Without those two bits of info we have absolutely no idea if it was a good rule.

Extremely low cost -- considering how easy it is to pop in a new private method, no big deal. Seconds, and not that frequently needed.

Extremely low benefit -- I wouldn't even notice, and most actually confusing things are bigger scale, like the confusing DAL "abstraction" that I was dragooned into copying from the wider C# community.

Yes. Seen and written. Maybe it's easier with a small team, and it's certainly easier with a good language (Scala in my case) but it's absolutely possible.

The discussion is more fairly framed as: Do you use abstraction (hide details) in your code base? Number of lines of code is, perhaps, a symptom of code that doesn't use abstraction well, but isn't proof. We need to see the the code base, understand its design goals, and how it's actually used before we can pass judgement.

> Has anyone seen production code with <=10 lines of code per function before?

I've seen code where many functions were like this, and very few were over 30 lines. It was easy to read. And it was tested and generally working well. Naming becomes important, but that's part of the point of extracting functions for readability.

Likewise, agreed. Very weird to see this article score high on HN.

I've written 2 line functions already. It depends. If you write scala or any functional language and you do pattern match it's sometimes more readable if you have something like

    blabla match {
        case 1 => func1
        case 2 => func2
    }

instead of

    blabla match {
        case 1 => 
            println("1")
            1 + 2
        case 2 => biggerFunc
    }

Reply on news.ycombinator.com