How do you make code reusable? [closed]

Question

See 10 tips on writing reusable code for some help.

1. Keep the code DRY. Dry means "Don't Repeat Yourself".
2. Make a class/method do just one thing.
3. Write unit tests for your classes AND make it easy to test classes.
4. Remove the business logic or main code away from any framework code
5. Try to think more abstractly and use Interfaces and Abstract classes.
6. Code for extension. Write code that can easily be extended in the future.
7. Don't write code that isn't needed.
8. Try to reduce coupling.
9. Be more Modular
10. Write code like your code is an External API

If you take the Test-Driven Development approach, then your code only becomes re-usable as your refactor based on forthcoming scenarios.

Personally I find constantly refactoring produces cleaner code than trying to second-guess what scenarios I need to code a particular class for.

More than anything else, maintainability makes code reusable.

Reusability is rarely a worthwhile goal in itself. Rather, it is a by-product of writing code that is well structured, easily maintainable and useful.

If you set out to make reusable code, you often find yourself trying to take into account requirements for behaviour that might be required in future projects. No matter how good you become at this, you'll find that you get these future-proofing requirements wrong.

On the other hand, if you start with the bare requirements of the current project, you will find that your code can be clean and tight and elegant. When you're working on another project that needs similar functionality, you will naturally adapt your original code.

I suggest looking at the best-practices for your chosen programming language / paradigm (eg. Patterns and SOLID for Java / C# types), the Lean / Agile programming literature, and (of course) the book "Code Complete". Understanding the advantages and disadvantages of these approaches will improve your coding practice no end. All your code will then become reausable - but 'by accident', rather than by design.

Also, see here: Writing Maintainable Code

You'll write various modules (parts) when writing a relatively big project. Reusable code in practice means you'll have create libraries that other projects needing that same functionality can use.

So, you have to identify modules that can be reused, for that

1. Identify the core competence of each module. For instance, if your project has to compress files, you'll have a module that will handle file compression. Do NOT make it do more than ONE THING. One thing only.

2. Write a library (or class) that will handle file compression, without needing anything more than the file to be compressed, the output and the compression format. This will decouple the module from the rest of the project, enabling it to be (re)used in a different setting.

3. You don't have to get it perfect the first time, when you actually reuse the library you will probably find out flaws in the design (for instance, you didn't make it modular enough to be able to add new compression formats easily) and you can fix them the second time around and improve the reusability of your module. The more you reuse it (and fix the flaws), the easier it'll become to reuse.

The most important thing to consider is decoupling, if you write tightly coupled code reusability is the first casualty.

Leave all the needed state or context outside the library. Add methods to specify the state to the library.

For most definitions of "reuse", reuse of code is a myth, at least in my experience. Can you tell I have some scars from this? :-)

By reuse, I don't mean taking existing source files and beating them into submission until a new component or service falls out. I mean taking a specific component or service and reusing it without alteration.

I think the first step is to get yourself into a mindset that it's going to take at least 3 iterations to create a reusable component. Why 3? Because the first time you try to reuse a component, you always discover something that it can't handle. So then you have to change it. This happens a couple of times, until finally you have a component that at least appears to be reusable.

The other approach is to do an expensive forward-looking design. But then the cost is all up-front, and the benefits (may) appear some time down the road. If your boss insists that the current project schedule always dominates, then this approach won't work.

Object-orientation allows you to refactor code into superclasses. This is perhaps the easiest, cheapest and most effective kind of reuse. Ordinary class inheritance doesn't require a lot of thinking about "other situations"; you don't have to build "omnipotent" code.

Beyond simple inheritance, reuse is something you find more than you invent. You find reuse situations when you want to reuse one of your own packages to solve a slightly different problem. When you want to reuse a package that doesn't precisely fit the new situation, you have two choices.

1. Copy it and fix it. You now have to nearly similar packages -- a costly mistake.

2. Make the original package reusable in two situations.

Just do that for reuse. Nothing more. Too much thinking about "potential" reuse and undefined "other situations" can become a waste of time.