From: jimw@math.umass.edu (Jim Weigang)
Newsgroups: comp.lang.apl
Date: 6 Feb 1995 02:46:30 GMT
Subject: Large vs small functions

Ah, one of the most artistic aspects of programming: How do you partition your code into manageable blocks? Ripe material for, um, discussion. I haven't read much that I agree with on this topic, so here is an attempt to describe my own instinctive habits.

I often write rather long functions (say, 200 lines). I support these programs and don't find them difficult to maintain, and other people I work with find it easy to understand and modify them as well. But I don't create 200-line functions without constraints. I've developed techniques for making these programs manageable:

These code paragraphs have some of the characteristics of small functions: They're manageably short. They implement a specific, stated task. (By looking only at the abstract and not the code you can suppress the detail of how the task is accomplished.) They are structurally self-contained with respect to branching.

Here's what I like about long functions written this way:

This is not to say that I don't use subroutines. I do, but I tend to create them only for specific reasons:

I believe the complexity of a subproblem is the main criterion I use in deciding whether to write a paragraph or a subroutine. For example, my calendar-printing program is 170 lines in 18 paragraphs. I felt no urge to break it into subroutines because the problem wasn't hard enough. On the other hand, ]FNTREE isn't much longer than this, but I wouldn't think of writing it monolithically. It's too hard a problem to deal with mentally all at once. Breaking it into subroutines reduced the complexity to something I could manage.

I've noticed that some people seem to think that writing small functions will make their applications easier to understand and/or maintain. I don't find this to be true. In fact, I find excessive subroutinization to be an impediment to understanding new code. Here's what I don't like about having lots of tiny functions:

My worst nightmare would be an application consisting of a thousand or so direct definition functions. Direct definition is great for including code in articles, where the prose takes the place of comments and the total amount of code is small, but a real-life application of significant complexity written as uncommented direct definition functions would be horrifying to deal with.

I want to emphasize that I'm not equating "big" with "good" here. A huge, monolithic function with deeply nested or unstructured branching can be a just as incomprehensible as a swarm of tiny undocumented subroutines. But a large function doesn't have to be indecipherable, and if your only technique for dividing code into blocks is to write separate functions, you're ignoring some very practical ways of writing clear, easily-maintained programs.

Jim


Home Page