Editor Coloring - Imagining an Engineering World with Less Suck

I watch a lot of Douglas Crockford videos. He likes to make fun of modern editors (maybe he uses Emacs) and he mocks syntax highlighting and autocompletion. This seems out of character for him because he talks a lot about how the purpose of code conventions is to avoid simple mistakes. That is the purpose of syntax highlighting and code completion. Errors arising from mismatched quotes are basically gone due to syntax highlighting.

He does make an interesting statement about coloring. He asks for an editor that does coloring based on scope. This got me thinking about how to use coloring effectively in editors. Then I started thinking about the Predator movie... In Predator the alien hunter uses infra red to track down his targets. Arnold smears mud on himself and that masks his heat signature. The Predator then manipulates his visor switching between several differently colored views.

So data visualization is a big topic and sub topic of it is code visualization. Crockford talks a little about how understanding your brain leads to making code that is better understood by brains (as opposed to machines). A little evolution... the mental capacities of human beings derive from the ability to analyze sensory input. When we compare human thinking and machine thinking, we humans completely trash machines at sensory analysis. Machines best humans in math. It is funny because some high functioning autistic savants talk about perceiving the world as numbers indicating they are using their visual processing abilities for math somehow.

Anyway, when we try and understand how computer systems are built we tend to draw arrows and boxes. What if we could write code by drawing pictures? Don't electrical engineers do this? Now some systems have been created to leverage visual processing like Windows Workflow. We have UML, (I don't use UML) that tries to add visual representation to object relationships.

Back to Predator. We us color to denote only one thing in code right now. It is the simplest thing to analyse so it was the first, and we have never really done anything else with text coloring. As our tools grow more powerful we could use color to give different information. We could use the Crockford example of coloring things based on their scope. For example, inside a method is all local variables were blue, class variables were purple, and passed in state was red it would give me a lot of instant information about the nature of the method. Right now we use cyclomatic complexity and coupling measures to give us a general indicator of code quality. We could reflect that in code coloring. As you added more code to a function it would suddenly turn red indicating you need to refactor. Why wait for some build report flagging your code as too complex. We have tools that determine what lines are unit tested and although I think this is largely bogus it is something that could be incorporated into editor coloring.

In some strategy games where you play on a map, you can add or subtract overlays that tell you about the state of the map. Imagine code like that. You could flip between colorings to give you information about the code.

As code becomes more complex we need to bridge the gap between our human brains and our computer brain tools. They work very differently and we need to take advantage of the power of both. Editor coloring is a good, simple way this could be done.