For many years now, I’ve had some crazy IDE (Integrated Development Environment) concepts or as my notes refer to ’em IDEas. LOL Now that I’ve been practicing the craft of programming for over 20 years, I’m starting to realize that we programmers suck at creating tools to make us better. We make incremental changes to IDEs, but basically not much has changed over time. I’d like to change that.
Below is a collection of my best ideas minus one. These ideas are free for the taking. I’ll never sue for money, demand royalties, ask for ownership of your company or any crap like that. Ideas are free, it’s the implementations that people own. Since I’m actually not implementing these ideas, I have no ownership. I think they’re really good ideas though, so I’m offering them here for free so that others can implement in their IDE tools.
IDEa #1: Hide everything but the current function
Programmers need to focus on the problem at hand in order to be successful. Even more so than that, they need to focus solely on the code they’re typing at that moment to insure it is good code. We’ve all seen blog posts and comics about why you shouldn’t bother a programmer. If that’s the case, then why do so many dang programmer tools overload your senses? Toolbars, buttons, tabs, windows, etc. All this crap to take up space and clutter your vision.
WordPress has this ability to remove all clutter from the screen except your text for the blog post. Then, when you move your mouse, a minimal amount of tools appear. They you can have the “kitchen sink” mode where you see all the zaniness that is the WP admin.
When I’m composing a new function/method, I want everything and I do mean everything else to disappear. I want no tools, no widgets, nothing but my new function. The code above it and below it should fade away. Doesn’t that leave a bunch of wasted space then? Yes, but that space can then be used to provide you with information you need.
Let’s say you type a variable name. As you do, in the space near the top of the screen you can have a simple dimmed overlay that shows you the variable declaration as well as where you first initialize that variables value. If you commented your code, you’d see those comments. In typed and object-oriented languages, as soon as you enter the type of item you’re going to use, a filtered list of those properties that you’ve declared of that type will show up above to help you figure out what to start typing to get that autocomplete. You could even click the var in the widget up top to have that property entered at that location of the cursor, but I’m a big proponent of not using the mouse so I’d just keep typing and use auto-complete.
Let’s say you use a function/method that you’ve already created in this file or another. The dimmed overlay up top now pulls in your code for that function. Instead of just autocompleting the header like most IDEs do, you now have instantaneous access to the code of the function/method you’re using. The arrow keys could be used to scroll your cursor in your current code, but then CTRL-Shift-ArrowUp/CTRL-Shift-ArrowDown could be used to scroll the overlay so you can skim through the code to figure out if indeed this is the function/method you need. If while scrolling you realize you’re going to need to edit the existing function to make it work, no problem. Hit CTRL-Shift-Enter and now the code in the overlay becomes the active code in the editor and becomes the point of focus. Once you’re done modifying it, hit CTRL-Shift-LeftArrow to go back to the method you were just editing and continue along you’re merry way.
Let’s say your using a method or variable in a class/object that is not your own code. In fact, it’s a closed systems architecture. No worries, put the documentation up in the overlay.
The key is to get you the information you need and that’s it, nothing else.
IDEa#2: Replace names of variables, function, classes, etc with icons
This should be the default view when you open up a file of code and before you start typing. Think of it as code folding 2.0. The icon can be inferred automatically by the editor and/or manually created by the programmer. This feature will help condense the code to make sure it’s all represented without the need to scroll, but still give you an idea of what the code structure is.
Let’s say I have a file that has 9 methods/functions in it and uses 2 types of properties.
The 9 functions are comprised of the following types: 3 that overload/extend existing functions, 3 that are user created logic and 3 event handler type functions. 1 property is a system type and the other is a user defined type.
Upon opening the file, I see 2 property icons and then 9 function icons and what they return. I can see right away the one of my methods returns the user defined type. Therefore, right away I know where to go if the bug/feature is requesting changes to that property type. If I need to fix a bug in an event handler, I can see which 3 methods are the handlers. I’d also add the ability to filter the file so I only see certain types of code to insure I don’t accidentally mess with something I shouldn’t.
IDEa #3: Shift between code & visual representation of code
I’m not talking about say a design view of UI code, but a graphical workflow of the code. Properties and methods would have a UML like graphical representation and arrows would show which methods branch out and call to other methods. You’d be able to see what handlers are tied to which properties, etc.
You should be able to create links and have the editor automatically add those calls to those methods in your code. Again, the idea is to get your focus on where it needs to be, which is making logical connections between the various pieces of your project’s code.
IDEa #4: Data Visualization for Code Usage/Analysis
This is more than just an IDE feature and could probably be its own stand alone tool. I suppose though, one could make it as a plugin/extension to an IDE. Since this tool involves Data Visualization, I went to the only Data Visualization Engineer that I know. Thus, this is a conversation with Doug McCune over IM where we flesh out the idea for the tool.
Thomas Ortega II
As I’ve been getting serious about the craft of programming, I got to thinking that IDE’s as a whole kinda suck for helping you understand your code. They’re great to code in, but don’t give you a bird’s-eye view. The only other real tools, aside from IDEs, are debuggers or profilers, etc. But that doesn’t help you with understanding your code…it just helps you find mem leaks and bugs due to bad logic/syntax in your code. So I thought about data visualization and how it could help you code.
Doug McCune
I’m with you so far.
Thomas Ortega II
And I thought, “What if every class was represented as a graph object. Then each graph object would be connected by lines that represented API calls. Each API call would be a different color.” This way, you can easily see which classes are overloaded and which are underutilized. It may also help you to see how you could balance the API load by separating out some logic. Then you could toggle to see which methods are never called, etc.
Doug McCune
So you’re saying, I have a little RandomObjectA and RandomObjectB and I’d see that A gets used a shitload by everything throughout my codebase, but B only gets called by one or two places?
Thomas Ortega II
Yup. Or B has some APIs that never get called at all. Coders can then see where a library would logically fall. “All these objects/classes call each other then reach out through a few APIs”
Doug McCune
Highlighting dead code/entire classes like that would certainly be useful, but I’m not sure what the usage visualization really tells you, other than what’s used more than other stuff. Something might be super duper important, but only used very infrequently.
Thomas Ortega II
Correct, I don’t think usage dictates bad design 100% of the time, but I’m guessing the majority of the time, you’d find out some useful stuff. Refactoring for a bug or new feature would be nicer with this data. Sure, an IDE shows who calls the code, but it also shows comments, every other function and var, etc. I think this would be faster/better in a refactor.
Doug McCune
One thing that might be interesting is to see if there’s a single point somewhere up a chain that would let you remove the need for a class altogether. So for example, we have a few “apps”, some of which are sort of dead, old customers, no longer used, etc so if I were to remove the entire package, which I’d like to do to clean things up, I could see all the other things that could get cleaned up outside of that. We have a bunch of common code that they might use, and within one of these dead apps something might get called a bunch, but it’s not used outside that package. Yeah, I mean, I could see some utility, I think in the end it’s about what’s “good enough” to get the job done a lot of time.
Thomas Ortega II
Yup, that’s a good use case for sure. You’re proving my second thought which is, you give this tool to coders and they’ll find new uses that I didn’t think of. LOL But I think coders need to create a wider/broader set of tools for ourselves. I figured with your data viz understanding and love to delete crap, that you’d know if it was good or lame idea right off that bat.
Another feature is the larger the file, i.e. more lines of actual code not comments, the larger the graph object representation. Again so you could see at a quick glance who the workhorses are. If this tiny guy is used a lot and this monster isn’t, is that because the tiny guy has better code? Is the monster big because it’s doing heavy lifting or cuz there’s lots of dead/useless code? Heck you could then drill down into a class and see the same thing internal to the class. Instead of graph objects being classes, they can now be methods and again the same rules apply: who calls who and size of object determines lines of code in the method.
A good use case would be for 3rd party lib makers, they could ask for a map by the customers and they could see what people are actually using so they’d know where to direct their effort. “Oh, we thought Feature A was the bees knees, but Feature B is actually used 500% more than Feature A. Time to shift priorities.”
That’s it
So those are my IDEas. All built as ways to help coders see their code in a different light than they normally do, quickly and easily. There’s one more idea, but since it’s not IDE specific, we’re actually going to build it. Stay tuned to learn more about it. I think it’s going to revolutionize how coders learn and teach one other as well as making coders better at what they do.
Feel free to comment, trash an IDEa or add to one. Shoot, if you’d like to add to the list, drop the idea in the comments and I’ll update the post with the ones I like. This page is for fellow coders to validate the needs for these features and for IDE makers to use as a very rough spec to build ’em.
