Martin Fowler introduced the concept of "code smells" in his book Refactoring, which I think is a clever way of explaining vague aesthetic notions in an intuitive, sensory way. I'm currently reading Structure and Interpretation of Computer Programs, the following two passages of which made me reflect on how I relate to code on a sensory level, a level more intangible and personal than one of classes, functions, filenames, and line numbers.
Every computer program is a model, hatched in the mind, of a real or mental process. These processes, arising from human experience and thought, are huge in number, intricate in detail, and at any time only partially understood. They are modeled to our permanent satisfaction rarely by our computer programs. Thus even though our programs are carefully handcrafted discrete collections of symbols, mosaics of interlocking functions, they continually evolve: we change them as our perception of the model deepens, enlarges, generalizes until the model ultimately attains a metastable place within still another model with which we struggle. The source of the exhilaration associated with computer programming is the continual unfolding within the mind and on the computer of mechanisms expressed as programs and the explosion of perception they generate. If art interprets our dreams, the computer executes them in the guise of programs!
...
Master software engineers have the ability to organize programs so that they can be reasonably sure that the resulting processes will perform the tasks intended. They can visualize the behavior of their systems in advance. They know how to structure programs so that unanticipated problems do not lead to catastrophic consequences, and when problems do arise, they can debug their programs. Well-designed computational systems, like well-designed automobiles or nuclear reactors, are designed in a modular manner, so that the parts can be constructed, replaced, and debugged separately.
After some reflection, I realized that below the surface, I have a mostly auditory model of program execution. For example, a script that processes logfiles has a simple, repetitive rhythm - one that probably varies with the nature of the process and it's input data. Algorithmic code I "hear" similarly, except the rhythm is more complex and accentuated, and varies according to the nature of the process - Dijkstra sounds different than a binary search.
Visualization is the most common way of expressing program execution as sensory data, like these call graphs of recursion and generator expressions in Python code:
But visualization is, in my opinion, a relatively high-level abstraction, and not the most personal, at least not for me. They say smell is the most emotionally evocative and memory-stimulating of the senses, and after a few weeks on vacation, I find myself forgetting what family members and close friends look like. Not completely, but the mental picture isn't as sharp, even after only a short time away.
I mentioned the sound of my code to my cube-neighbor Greg, half-expecting him to tell me to lay off the LSD. He didn't think I was crazy, and related his internal model to me, one that was more visual - "textures" was the main abstraction he seemed to have.
I think a large part of the learning curve involved with learning new codebases, even after reading the API docs, knowing the module layout, maybe even reading some of the source, is the lack of a low level sensory model of how that code runs. I know I have one of these for Twisted (and asynchronous programming in general), and it differs from that of threaded code, but I'm afraid I lack the language to describe it, because its components are so integral to all the abstractions I build, including language.
Expressible or not, I think exploring and understanding one's own low-level models of how their programs behave is valuable. Does anyone have other interesting models? Can any chefs out there taste their code? Or should I lay off the LSD :) ? |
