by Leon Rosenshein


How big is too big? How small is too small? How do you decide? What criteria goes into the decision? A good place to start thinking about this is the Unix Philosophy. Small and simple. Composable. Do one thing and do it well.

And you can apply it at just about any level you want. Functions should be small and single purpose. It would be odd to see a function called `HandleFile(...)` that parsed it's inputs and sometimes printed a file, sometimes executed it, and sometimes deleted it. Similarly, you don't expect your graphics library to render images to a canvas and control a robot. Going even broader in scope, Microsoft Office and the Google Suite are collections of (mostly) single purpose tools (documents, spreadsheets, drawing, presentation) that are composable and look/feel like they belong together. But you don't want or expect to use them to control a 6 axis CNC mill.

You can go even larger than that. Think about a distributed microservice architecture. The microservices act as functions/libraries in a larger system. Separation of concerns and bounded contexts help you keep things "simple". Whether you're talking about a function, library, tool, application, or service, knowing where the boundaries are lets you maintain context.

So keep things small. Good advice. but like any other piece of advice, you can take it too far. You can make things too small. If your boilerplate comment block is larger than most of your functions you've probably gone too small. If, instead of ls and and option to be recursive (ls -R) or show attributes (ls -l) you have new commands for each option (lsr, lsl, lsa, etc) you've gone too far.