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.