Tuesday, April 04, 2006
Gestalt Code Reading
This is a follow up from some considerations in the comment section of the previous post.
If you have been writing code for some time I am sure that from time to time you also experience the weird psycognostic power of gestalt-reading code. When I say gestalt-reading I mean that feeling of absorbing the main points and relationships of code by simply giving it a quick glance, just flicking through several pages of code.
You don't know exactly what you have read, but you somehow have an overall impression of what the code does and how the different abstractions are related.
What do you think this is due to?
I believe it is a mix of code indentation, code conventions, general domain culture and the ability of visualizing code on the fly via iconic images. Next time you use your superpowers pay attention to what is happening within your perception process. If your perceptual habits are even a little bit similar to mine, you will probably notice that when you read code you see little boxes and arrows, popping into existence on the backstage of your counscius awareness, connecting together according to well-known patterns.
The knowledge of this process may turn out to be quite important when deciding what code should look like. Proper alignment of braces and indentations.. the feeling of un-closure that I sometimes feel when looking at python code (it feels more like a flow than like legos). My mind looks for visual patterns and simplifies them into icons and boxes, probably also relying on subtler cues and unconscious processes to build meaning.
It's interesting to see what information we can get from this kind of code reading. I can get the main conceptual entities because I can visually spot classes and attributes. I can get the broader relationships too, probably because of a good rational choice of class names, sometimes due to the naming of attributes, occasionally by seeing how some object instances are built and attached to each other. I rarely get the algorithms at a first glance, although I seem to remember that I used to be able to, before doing OOP.. but I am not sure if that really was the case, in the same way as I can do it now with objects. One thing is for sure: much of the metaprogramming cleverness is lost.
However, if the metaprogramming could be kept simple and regular and visually striking, then it could be absorbed much more easily. Think about ActiveRecord. Maybe it doesn't matter so much how we say something, as long as we can make it visually recognisable and compelling, so that it promotes easy visual parsing.
I was almost giving all sorts of non-visual code reading now, and I was forgetting test code. Test code is a conspicuous exception to what I have just said about visual parsing. If a project has tests I prefer to read the tests rather than the project code. Tests are better at capturing the intent of the code and the way to interact with it. They also clearly capture the dynamics of instances, providing not only a compositional/structural view of code, but also the modes of interaction with the code. However tests must be read and cannot be simply absobed using gestalt-reading. Maybe that's because they tend to specify behaviour rather than structure...
If you have been writing code for some time I am sure that from time to time you also experience the weird psycognostic power of gestalt-reading code. When I say gestalt-reading I mean that feeling of absorbing the main points and relationships of code by simply giving it a quick glance, just flicking through several pages of code.
You don't know exactly what you have read, but you somehow have an overall impression of what the code does and how the different abstractions are related.
What do you think this is due to?
I believe it is a mix of code indentation, code conventions, general domain culture and the ability of visualizing code on the fly via iconic images. Next time you use your superpowers pay attention to what is happening within your perception process. If your perceptual habits are even a little bit similar to mine, you will probably notice that when you read code you see little boxes and arrows, popping into existence on the backstage of your counscius awareness, connecting together according to well-known patterns.
The knowledge of this process may turn out to be quite important when deciding what code should look like. Proper alignment of braces and indentations.. the feeling of un-closure that I sometimes feel when looking at python code (it feels more like a flow than like legos). My mind looks for visual patterns and simplifies them into icons and boxes, probably also relying on subtler cues and unconscious processes to build meaning.
It's interesting to see what information we can get from this kind of code reading. I can get the main conceptual entities because I can visually spot classes and attributes. I can get the broader relationships too, probably because of a good rational choice of class names, sometimes due to the naming of attributes, occasionally by seeing how some object instances are built and attached to each other. I rarely get the algorithms at a first glance, although I seem to remember that I used to be able to, before doing OOP.. but I am not sure if that really was the case, in the same way as I can do it now with objects. One thing is for sure: much of the metaprogramming cleverness is lost.
However, if the metaprogramming could be kept simple and regular and visually striking, then it could be absorbed much more easily. Think about ActiveRecord. Maybe it doesn't matter so much how we say something, as long as we can make it visually recognisable and compelling, so that it promotes easy visual parsing.
I was almost giving all sorts of non-visual code reading now, and I was forgetting test code. Test code is a conspicuous exception to what I have just said about visual parsing. If a project has tests I prefer to read the tests rather than the project code. Tests are better at capturing the intent of the code and the way to interact with it. They also clearly capture the dynamics of instances, providing not only a compositional/structural view of code, but also the modes of interaction with the code. However tests must be read and cannot be simply absobed using gestalt-reading. Maybe that's because they tend to specify behaviour rather than structure...
