Design code toward library quality

Better code is correct, efficient, and reusable. As an industry we produce so much code that is a one-off. It is such a waste of time and talent. I try to encourage every developer to write all code as if it were going to be part of a library, ideally part of the standard, and to use library components. - Sean Parent on https://www.meetingcpp.com

Even if your code will never become a reusable library, this mindset encourages better design decisions.

It’s not necessary to always design towards a library. If your code naturally evolves towards it, it is a sign you are following good design practices. Conversely, if your codebase consists mainly of units that are single purpose and difficult to reuse, then you will likely struggle with maintaining and extending it. Take this as a sign that you might need to refactor.

The value of library-like design isn’t strictly in enabling reuse, it’s that library-quality thinking prevents design shortcuts that create maintenance headaches later.

Characteristics of a library quality

Library quality is all about interfaces and separation of concerns. Library quality interfaces do not assume specific and specialized usecases, instead they provide general access to functionality, allowing a variety of clients to satisfy a variety of usecases.

When you create an interface, don’t assume you know the context and usecase that it will be used in. You probably do have one in mind, but assume that there will be others that you are not aware of. Otherwise, you risk building assumptions into the code. Building assumptions into the code can not only prevent future reuse, it can also mislead and be error prone. (Example?)

• Composability
• Reusability
• Variability (or configurability?)