Sunday, June 03, 2007

code hygiene

A blog entry about code reuse through "recontexting" used the term "hygienic code", and I must admit that it left me confused at first. One of the comments asked for clarification. The meaning of "hygienic code", expressed in a follow-up comment, was "Hygienic code does exactly the task at hand, without introducing anything extraneous. As an example, rigorous application of AOP can be pretty hygienic, if all cross-cutting concerns can be implemented as aspects."

My confusion arose out of the way that I understand the definition of a hygienic macro, because recontexting appeared to do the opposite. (Side comment: I seem to recall reading once that un-hygienic macros, while harder to use, can accomplish particular tricks easier than hygienic macros). If code is hygienic when the reused code (whether macro or function) and the context code have no side-effect transformations of variables, then shouldn't it therefore not be hygienic when code undergoes recontexting, where recontexting consists of directly changing the meaning of a symbol in the reused code? Maybe this is what the blog author is alluding to in a later follow-up comment: "And, BTW, all of these approaches [OO, dependency injection, "hygienic"] have been criticized for their reliance on runtime black magic." Code that runs differently depending on context (as opposed to parameterized code that runs differently depending on arguments passed in) can be harder to trace. It's not that far removed in actuality from code that refers to global variables.

On the other hand, as the blog entry says, recontexting code has the unenviable goal of trying to reuse code without 1) originally writing the code to be reusable, or even 2) modifying the code at the time of reuse to be reusable. Also, the fact that the context is explicitly treated as a code configuration setting (reminiscent of an application.xml) makes it more acceptable to me than, for instance, a procedure that loads a class at runtime, changes it five ways, then passes the class (probably an instance, actually) to another procedure. I prefer to not take dogmatic stances on software development, but instead loudly point out the tradeoffs.

It's amazing how code can morph when one throws strict (compile-time or run-time) code contracts out the window.

1 comment:

  1. I can't process all that you are saying here but if you will: consider walls as parameters for a bit or terabyte of info, then if they, the walls, are only (OS :) algorithms, which can be altered with other algorithms, will IP addresses need to be stamped on the package itself? Or simply remote controlled from sender? What brought me here was my minds brain waves, with a little direction from google and a keypad :)