How to Write Re-usable Code

In my software quality sessions, one of my favorite questions had been “how to write re-usable code”. The most common answer has been following:

Once one identified the re-usable components based on the functionality, once can write the components accordingly such that it can be reused. However, this argument required one to identify the reusable components at the design time. The question still remained. How would one write a code that can be termed as re-usable even if the component is not required to be reused at the moment?

Another question that I ask is if it is possible to look at the code and say if this is a reusable code. The most common answer as expected is NO. Well, YES, it is possible to look at the code and say if it is a reusable code or not.

• Reusability is directly associated with cohesiveness of the code. Cohesive code is one which serve single functionality.
• Higher the cohesiveness, lower the coupling, higher the reusability.
• 3. If a block of code is found to be serving multiple functionality, or low in cohesion, there are high chances that code may not get reused. The reason is very simple. If the code is serving multiple functionality, a new module would not want to use the component for one of the functionality that it serves mainly because the component can be changed for other functionalities which may depend upon this functionality.
• 4. Mathematically, following is how it looks like:

A component C serves multiple functionality. This can also be represented as following:

C = f(x) + g(y) + h(z)

There are another components such as A1 which uses C for functionality f(x), A2 which uses C for g(y) and A3 which uses for h(z).

A1 depends on C for f(x)
A2 depends on C for g(y)
A3 depends on C for h(z)

A new component A4 may not use C for f(x) because at any point, f(x) may be internally called by g(x) and a change in functionality requirement of A2 may force g(x) to change f(x). Thus, although component C looked like as an reusable component from outward, in reality, it may not be used as reusable component as it may break.

• Thus, to write a reusable code, make sure that software entity consisting that code should do just one thing, or follow single responsibility principle (SRP).
• Code smells such as long classes, long methods should act as warning for non-reusable components.