4 ms·

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 r

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.

Etheryte 11y ago
Likewise, agreed. Very weird to see this article score high on HN.
lmm 11y ago
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.
jakobegger 11y ago
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.
SuddsMcDuff 11y ago
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.
- moonshinefe 11y ago
  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
  - SuddsMcDuff 11y ago
    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.
jernfrost 11y ago
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.
krylon 11y ago
> 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.
- deleted 11y ago
  [deleted]
- moonshinefe 11y ago
  Agreed.
- SideburnsOfDoom 11y ago
  > 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?
  - moonshinefe 11y ago
    I actually missed that one part of his response when I agreed in reply. 750 lines is definitely a red flag for refactoring.
rimantas 11y ago
You might want to see this: https://www.youtube.com/watch?v=npOGOmkxuio 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 https://www.youtube.com/watch?v=8bZh5LMaSmE
- moonshinefe 11y ago
  She seems like a great speaker, will bookmark for later. TY.
  - mercer 11y ago
    Her book "Practical Object-Oriented Design in Ruby"[1] is also quite good [1]: http://www.poodr.com/ http://www.poodr.com/
- SwellJoe 11y ago
  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.
merb 11y ago
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 }
jt2190 11y ago
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.
hawkice 11y ago
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.
- Dylan16807 11y ago
  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.
  - hawkice 11y ago
    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.
eric_bullington 11y ago
> 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.
SideburnsOfDoom 11y ago
> 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.
whiddershins 11y ago
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.
deleted 11y ago
[deleted]

Etheryte 11y ago

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

lmm 11y ago

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.

jakobegger 11y ago

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.

SuddsMcDuff 11y ago

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.

moonshinefe 11y ago
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
- SuddsMcDuff 11y ago
  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.

jernfrost 11y ago

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.

krylon 11y ago

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

deleted 11y ago
[deleted]
moonshinefe 11y ago
Agreed.
SideburnsOfDoom 11y ago
> 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?
- moonshinefe 11y ago
  I actually missed that one part of his response when I agreed in reply. 750 lines is definitely a red flag for refactoring.

rimantas 11y ago

You might want to see this: https://www.youtube.com/watch?v=npOGOmkxuio 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 https://www.youtube.com/watch?v=8bZh5LMaSmE

moonshinefe 11y ago
She seems like a great speaker, will bookmark for later. TY.
- mercer 11y ago
  Her book "Practical Object-Oriented Design in Ruby"[1] is also quite good [1]: http://www.poodr.com/ http://www.poodr.com/
SwellJoe 11y ago
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.

merb 11y ago

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 }

jt2190 11y ago

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.

hawkice 11y ago

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.

Dylan16807 11y ago
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.
- hawkice 11y ago
  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.

eric_bullington 11y ago

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

SideburnsOfDoom 11y ago

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

whiddershins 11y ago

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.

deleted 11y ago

[deleted]