Code reuse is the practice of using the same segment of code in multiple applications. This can be accomplished in many different ways, such as distributing source code, using an operating system's compiled libraries, or over a network using another system's APIs.
- Reusing code saves programming time, which reduces costs. If one person or team has already solved a problem, and they share the solution, there's no need to solve the problem again (with some potential caveats - see Drawbacks).
- Sharing code can help prevent bugs by reducing the amount of total code that needs to be written to perform a set of tasks. Generally, the more code a system contains, the more bugs it's likely to have. The shared code can also be tested separately from the applications which use it.
- Separating code into common libraries lets programmers specialize in their particular strengths. A security library, for example, can be built by security experts while a user interface which uses the library can let UI experts focus on their tasks.
- Relatedly, separating code into specialized libraries lets each be tuned for performance, security, and special cases. For example, a Python application might delegate graphics functionality to a C library for performance.
- Delegation of tasks into shared modules allows offloading of some functionality onto separate systems. For example, a system specialized for fast read-only database queries can be used for reporting and accessed by multiple desktop applications.
- Proper and efficient reuse of code can help avoid code bloat. Bloated code contains unnecessary duplication and unused instructions. By efficiently sharing code across systems each individual component avoids duplicate or unneeded functionality.
There can be important tradeoffs between reusing someone else's code and implementing your own solution. For example, a 3rd party library might be slower or less robust, but using it to reduce programming time might be worthwhile over re-implementing a custom library. The choice depends on the situation at hand.
There are other potential drawbacks to code reuse, often very dependent on the situation and implementation:
- Performance might become a factor.
- Depending on the platform and programming language, a library or framework might perform slower than desired. In some situations it might be beneficial to build a specialized one-time solution instead of using a common library.
- APIs accessed over a network will sometimes be slower than solving a problem within the local system.
- The system of modularity itself might create a bottleneck. For example, extra process initialization or shared library management can create overhead.
- Loss of control over 3rd party solutions might have negative repercussions. For example, there might be lack of support, desired feature enhancements might not get added, or security might not be fully tested. Outside the technical considerations, there might also be licensing and liability issues.
- When not well implemented or when taken too far, code reuse can eventually cause code bloat. Ironically, adding modularity can eventually lead to lingering APIs and libraries which go unused. In very large systems it's not uncommon to lose track of how every component is used. Over time a component may become useless, but linger in the system. This, however, is not so much an inherent drawback of code reuse as it's a problem of implementation.
Code reuse is promoted through: