3.14 Libraries

What you need to know

• A software library is a collection of procedures that can be used in other programs — often written and tested by other developers.
• Benefits: save development time, reuse code that's already been debugged, and gain capabilities (graphics, networking, math) you'd otherwise have to build yourself.
• An API (application programming interface) specifies how a library's procedures are called: their names, parameters, and what they return. It's the contract between your code and the library.
• Documentation is essential for using a library correctly — it explains what each procedure does, what it needs, and how it behaves in edge cases. You can't use a library well without it.
• Using a library is procedural abstraction in practice: you call sort(list) without knowing the sorting algorithm inside.
• Libraries are typically imported into a program before their procedures can be called.

Worked example

Suppose a math library's documentation says: ROUND(x, places) returns x rounded to the given number of decimal places. You never see the rounding code; you just call ROUND(3.14159, 2) and get 3.14. If the documentation had said the second parameter is the number of significant figures, the same call would return 3.1. Reading the API, not guessing, is the skill.

Going deeper

The nuance, edge cases, and connections that turn a 3 into a 5.

• A library is a collection of procedures (and sometimes data) that other programs can use. The procedures were written, tested, and documented by someone else — that's the value: you don't redo their work.
• An API specifies how to use a library: the procedure names, what to pass in, what comes back. You program against the API. The implementation behind it can change without your code changing, as long as the API stays the same.
• Documentation is the CED's emphasis: you can't use a library correctly without reading how each procedure behaves — what it expects, what it returns, what happens in edge cases. A question describing a developer who "read the documentation to understand the parameters" is describing correct library use.
• Libraries make development faster (don't rewrite tested code) and programs more reliable (widely-used libraries have had their bugs found). They also give access to capabilities you couldn't build yourself — graphics, networking, machine learning.
• Using a library is procedural abstraction at scale: you call sortList(list) without knowing whether it uses merge sort or quicksort. The abstraction is the whole point.
• Libraries are also a collaboration mechanism (1.1) — the people who wrote the library are, in effect, on your team.

Mistakes that cost points

• Assuming you need the source code. You use a library through its API. Options saying "the developer must understand the library's implementation" are wrong.
• Claiming libraries guarantee correctness. They're usually well-tested, but calling them with the wrong arguments still produces wrong results — hence documentation.
• Confusing a library with a language feature. Built-in operators (+, MOD) aren't library calls. A library adds procedures beyond what the language provides.

Practice questions

Written in the style of the real exam. Try each one before revealing the answer.