On Monday morning I pulled down the latest .NET Rocks! show to listen to while I worked. I do this every Monday since it gets me into the mood for some serious coding and also gives me a few good URLs to click once I get back to an Internet connection.
This Monday however I was surprised to find that listen among the URLs was a link to this old post of mine, it was also mentioned during the show. Cool! I await the .NET Rocks! effect :)
Anyway, Mark Miller had some feedback for me on the Code Builders idea. Unless I missed something I think it boiled down to two things:
- Don't obscure the code underneath the builder.
- Builders could indicate that the programming model is flawed.
This is very good feedback and I would like to address it in this post. First off I totally agree with the first one, this was one side-effect of code builders that I struggled with when designing this hypothetical feature. The only way that I can see to retain the code builder feature and not obscure the code would be to slide the code on the lines below down. On lower resolutions this would probably mean sliding the code out of the viewable area anyway so that plus the distraction of the actual slide effect itself might make it pointless.
The second suggestion was that the builders could indicate that the programming model is flawed, I disagree (insert shock sound <here>). The reason I say that is because I feel that with code builders we could made the process of cutting code more inductive, as opposed to deductive, its not necessarily a reflection on the API itself.
Most of us wouldn't dream of using a code editor today without syntax highlighting and intellisense (OK, so .NET developers are a little bit spoilt). But even with intellisense finding your way around even the most simple API's can be cumbersome. So where code builders can help out is when you are dealing with a complex syntax like XPath (the XPath spec constrains how much more simple you can make this) or boilerplate code like like loading a resource or a configuration setting to pass into an API (admittedly this is made much easier with Whidbey anyway).
So finally, I took a pass over the .NET Framework and looked at the namespaces that I thought could benefit from code builders.
- System.CodeDom (for dynamic code generation)
- System.Collections (for doing things like tuning collection sizes and growth)
- System.Drawing (for things like GDI+ object construction)
- System.Diagnostics (for building trace code)
- System.IO (for designing IO pipelines)
I didn't even get through the whole list but there is probably half a dozen common ones in there plus a few specific ones for the more hairy APIs. Anyway, I wanted to thank Rory, Carl and Mark for sending some traffic my way but also for the feedback. If nothing else it has added a few votes to the suggestion in LadyBug :)