|February 23rd, 2009|
|programming, repurposeability, tech|
Given that we are always constructing models of problems and nearly always must begin before our understanding is total, times when we must repurpose our code are unavoidable. Then this presents a metric for evaluating a programming style or language: repurposeability. That is, when one writes code in this fashion and finds out that one was solving the wrong problem, how much work is needed to repurpose it to solve the problem one should have been solving all along?
Repurposability is the driving force behind many aspects of good
coding style. The avoidance of duplicate code, for example. Say
you need to send some debugging output to a file instead of
standard output. In java you might have a gui program with
hundreds of calls to "
System.out.writeln()" that really
should be calls to some debug function. So this is a programming
style issue. It is also a programming language issue, though. In
common lisp one might deal with this problem with a statement
equivalent to "in the code called from here, substitute this
System.out". Similarly in java, you might
have hundreds of reads and writes to the object attribute
Foo.bar". The standard arguments for java tell you to
make them be to "
Foo.getBar()" instead, so if you later change your mind
you don't have to change all those references to
Foo.bar". The advice is so to maximize
repurposeability. But in python one would solve the same problem
Foo.bar all along and taking advantage of the
ability to wrap it in getters and seters later if needed.
I need to think more about what is needed for repurposeability, but it certainly sounds like a useful metric.
Comment via: facebook