Why limit function size?

I've always thought this was stupid. Not that long functions are good, but an arbitrary, artificial limit misses the point of smaller functions and encourages "procedural program page 2" type functions. That is, until I was talked with a developer I really respect about it. He said that in the 80's his limit was 24 lines. Today, it's more.

He explained that his limit to function size is the number of lines that fit on a screen. The argument being that one developer can only hold one screen's worth of information in their head at one time.

Line limits as a complimentary philosophy

I realized through our conversation that I was hoping that a line limit would teach problem decomposition. I now believe that decomposition and line limits must be taught in parallel.

Without decomposition techniques, line limits do devolve into "page 2" type functions - functions which don't abstract anything, but are simply continued on "page 2." This doesn't mean that line limits are bad. Test driven development is the same way.

TDD must be paired with understanding about how to support refactoring and how to design from the outside in. Experience with the rigid structure of TDD without true regard for its purpose builds strong resentment for the paradigm.

As a guide for abstraction

Every line of code adds one point of complexity and every level of abstraction adds 10. It's not that abstraction shouldn't happen, but consider whether you are hiding things you'll care about when you go back and read your code. Line limits give us some idea for how far to abstract things. You don't need to jump to a new method every line, but you should only care about what's happening in your code at a level that fits on one screen. Then if you need to know how a certain portion of your routine works in a more fine grained way, you're free to drill into that area of code.

Where to go from here

1. Find out what your line limit is. Go to your IDE and check how many lines fit on a screen.
2. Research "computational thinking." I mentioned program decomposition and abstraction in this post. These are two of the four principles of computational thinking.

Respond to this post and join the conversation on DEV