A well structured library will contain functions that are grouped together in a same logical unit to help you perform a set of tasks more easily. This could be reading graphics files, or managing time and dates. Good libraries include just enough functions so that you have access to the complete functionality, but nothing superfluous.
Too often, libraries catch featuritis and grow large with less used functions that were added at some point to scratch a minor hitch. Worst, you discover functions hidden in a library that you’re not sure what to do with them, but sometimes, you find functions that are positively stupid. What is even more surprising is where you can find them. I found a couple in the GNU C Library.
The first utterly stupid function is memfrob. Pulling up the man page for memfrob, you discover that its goal in life is to “frobnicate” a chunk of memory by xoring it with the number 42. Apparently, it is provided as an example of trivial encryption. That I can understand. What I can’t understand, is that it made its way into the GNU C library. This is a useless function that adds complexity—albeit negligible—to an already large library.
The other one that for which I cannot fathom a use, is strfry. strfry uses rand to shuffle the characters in a null-terminated string to yield an anagram of the original string. Hmm… ok… but what for? Randomizing keys for storage in a data structure? Well, that could work if somehow it could generate the same anagram for the same given input, but, lo! it doesn’t. To do that, it should compute some kind of hash to initialize the random seed, but to that point, you’d be better off using a real hash function for table look-ups.
I think that memfrob and strfry are two textbook examples of what not to include in a library. They’re not general. They’re bad at what they’re doing. They’re not even useful. They use space and require maintenance. They’re basically a nuisance. If you answer me that “if you don’t like them, don’t use them”, I shall taunt you a second time, because you’ve really missed the point.
So when you design a library, think about each function you add. Ask yourself if you’re adding some memfrob function? Is that something that could be better computed using another function—including from another library. Are you adding complexity to provide your prospective users a minor helper function? Are you adding something that is broken by design? If you answer yes or maybe to any of these questions, just don’t add the damn function. If you think that a user may want something that’s not a core functionality, let them code it. Provide only the solid, useful, well thought-out core components.
Less is more.