A code editor that doesn’t use the document metaphor
I dare say all main code editors today use the document metaphor; text in a document read from top to bottom.
I dare say time has come to drop this metaphor to a more object oriented or data flow oriented one.
When writing a class in an object oriented language the resulting document usually, contains the properties in the top and the methods below.
This means that when looking at the code reading a property name means it is easy to read other properties as they are close by in the document. But is this really what you want? – isn’t the methods using this property what you want to look at?
Now say you are debugging the Save method. There is a great chance you have method Restore (alphabet wise R is next to S) on the monitor; despite you being totally uninterested in them.
What you instead want to have before your eyes and withing a keystroke are the properties User and IsAdministrator and the method Validate; because they are part of the data flow method Save uses.
You are probably also interested in who calls Save and who is called by Save.
My proposal is this:
When you are working with a method, in your vicinity you want what Save reads and manipulates. Any property is shown in a window above the method you are working with. To the right you have a list of methods, and possibly some code, to all methods that are called from the method you are working with and to the left you can see all ways to call your method.
Equally easy to see and navigate to are the parents and descendants of your class.
Many IDE:s already (partially) compiles your code while you type in order to provide early warnings and errors as well as autocompletion suggestions. While doing that, I suppose they build parse syntax trees from the code, and by changing from editing text to editing trees, should be relatively easy.
A challenge is of course how to store the code, both for building and in version control systems. But it wouldn’t be impossible to reverse the process and generate text files from the syntax tree.
As an extra bonus, it would make and end to the code formatting style wars. The text file generator could generate code as the most impassioned people require, and everyone else can ignore that and have the code look as they wish 😉
You are taking my solution even further, into a future post of mine; where I describe how we can store the parse tree instead of the source code.
That way we will have better diff/merge capabilities where moving a method doesn’t make the whole source code document light up like a christmas tree.
When that is finished I plan to write about how we then can treat the code as changes of functionality-blocks instead of changes of written text.
Regarding the formatting style war you are on to something but I see problems.
One is that different projects has different formatting needs. I.e. my test project is different from my production project.
Another is where one wants to format differently than the personal standard. Presently I have several such cases where readability trumps rigorous formatting style. This is solvable to 99%. Which should be enough.