Yes. Reason: Any function is likely to be called from more than 1 place, so, is this “reuse”? Or just “use”? I have seen code to become less usable since it was designed with params, configs, bells and whistles to make it more “reusable” – for unforeseen “future” use.

I think, it was in his book “Smalltalk Best Practice Patterns”, that Kent Beck argued, we should make our code usable in the first place before we think about reusability; and we should strive to make it changeable rather than reusable since we cannot foresee, what (currently unneeded!) extra features and parameters (who will test all this?) we need to add to satisfy “future” requests.

I plead for a small amount of “controls/parameters” in our code to make it more usable, i.e. “short term reusable” in the foreseeable near future … fluminis said it already: even in our applications we do not want to duplicate work, so we need to design for our own use.

For such case, my feeling is that a “less ambitious” library for one’s own purpose might often be so much simpler than a professional one (for a much larger audience!) – which we maybe should reuse – that the simple homegrown solution can be the better (easier to learn and debug) choice … especially if you can make it so simple that its code is very changeable (as Beck suggested): then it might be easy to adapt it to future requirements as soon as they get known … maybe at least as easy as trying to figure out how the more complex “truly flexible” library functions from the pros can be tweaked by passing optional parameters or setting values in some configuration files.

To sum it up:
The most important goals are
1) simplicity while maintaining correctness
2) proper design for “current use” (in fact implied by correctness)
3) a coding style that eases changes in the codebase
my 2c

Or even more :

“Don’t learn about computers. Young people, born with an iPad in their hands, will get past you soon… Learn management and outsourcing instead”.

I do think that you need to go through the basics, all of them. Refactoring, writing / thinking about how to write reusable code. Until it becomes automagic. And you master the subject enough to be able to decide
- when to write code
- when to spend time making it reusable
- when to leverage other people’s work…

Nearly every single developers already implements the logic you describe at a basic level, by not reimplementing the Sine or Sqrt function when he needs them.

Don’t assume you know what the future will bring, predicting the future correctly is exquisitely difficult. Of course if you already have requirements for 50 similar solutions, well that’s ‘use’.

There is a legitimate debate about dependencies vs. reusable code, but not here…

Reuse should emerge as a result of good design. What I mean by that is when a piece of code solves a highly focused problem (i.e Single Responsibility) with as few external responsibilities\interactions as possible, then it is easy to reuse that piece of code. The SOLID principles are the principles of design optimisation for maintainability and reuse. Although they are presented with a focus on OO, they apply to any language where the relationships relevant to the principle can be expressed in that language.

I completely agree with the idea of don’t reinvent the wheel though.

http://www.reddit.com/r/programming/comments/16xrmu/dont_design_for_reuse_more_hilarity_from_the/

A 3rd scenario where reusability is important is when we wish to have uniform developer idioms throughout a codebase. Often times its easier to rewrite a component that exists, or wrap it, in such a way that it more naturally interacts with our API. When we do this, our components need to be reusable.