1

Background

I came across this question about whether few big libraries, or many small libraries is better.

I tend to agree with the accepted answer, that many small libraries is better.

However, since there is some overhead with creating and referencing a library, I came to wonder, how small is too small?

Questions

Are there circumstances where it would be reasonable to create a library for a single file?

For example, would any of the following be reasonable to have a library all to itself?

  1. The configuration class
  2. Common base classes
    • Base class for handling updating the UI on property changes
    • Common ViewModelBaseClasses (in MVVM architecture) for pages & subpages
  3. Common utilities
    • String parsers
    • String formatters
    • Mathematical operations
    • Generic Algorithms
    • Validation logic
  4. Common exit codes or exceptions
    • If we want to standardize the exit codes across all of our applications, would it make sense to have a library that just contains our exit codes?
  5. Magic constants
    • If there are a set of values that we use all the time, across many applications, but don't exist in any
  6. Common test configurations
    • For unit testing, should the common test configurations be in their own package?
4
  • left-pad Commented May 1 at 21:51
  • @PhilipKendall I'm not sure if you are arguing for or against here. Sounds like very small libraries/packages are common, but could be risky if someone just deletes it.
    – Tyler
    Commented May 2 at 11:53
  • @PhilipKendall I raise your left-pad with a true.
    – JimmyJames
    Commented May 2 at 17:03
  • Avoid consuming third party 1/couple line libraries. You just increase security and maintenance risks at the price of saving X seconds writing the code. Commented May 8 at 13:27

1 Answer 1

6

For me it comes down to reuse and genericism. DRY vs WET

If you make a package you expect to reuse that code in lots of places, for that to work it has to be a generic solution and it has to be complete.

A non generic solution, say LeftPad1() which adds a single character won't get reused as someone is bound to need LeftPad2() or 3 at some point and then you need to change the package

An incomplete package say Math.PlusMinusMultiplyButNotDivide is the same, you are going to have to go back and add Divide at some point for it to be useful as a package.

If you change a package, you potentially break everything that uses it. It's not something to do lightly.

All code is littered with non-generic, non-complete functions, because you only implement what you need for that program. Making generic, complete versions of those functions is hard and more work.

So don't turn all your config as code, presentation layer string formatting and random helper functions into libraries. They are specific to your application. You need to be able to change them and not break other applications.

Do turn your generic, completed, finished functions into libraries. You won't need to change them and they can be reused.

3
  • 2
    +1 a lot of people forget about the complete part.
    – Ccm
    Commented May 2 at 6:49
  • So if it is generic, complete, & very unlikely to need to be changed, then it is okay to turn it into library/package, regardless of size?
    – Tyler
    Commented May 2 at 11:55
  • 1
    yes, although those requirements will exclude most tiny things
    – Ewan
    Commented May 2 at 12:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.