Code generation comes in many forms, shapes, and formats. Most of us already use code generation, often daily. Whenever you type “dotnet new …” or “ng generate …” or many other such command-line tools, code is generated. Or when Entity Framework requests data from a database, a SQL query is generated then executed. Some code is generated at design time, some at compile-time, some at run time, in the end, it’s all code generation.
However, for me, I use the term code generation to represent something more. Maybe it’s something else and I haven’t found the right name for it? I use code generation in all its other forms every day, it’s just a part of my workflow. But, when I think Code Generation, with a capital C and G, it’s bigger than that.
Where did this come from?
While I did write code generating code way before that, I started pursuing this when I discovered the Visual Studio Modeling SDK. That was in the early 2000s (2003 I think). The SDK introduced me to the concept of Domain Specific Language (DSL) and many of the tools that were required to support it. Right there and then, I knew what I wanted to do…
I wanted to generate entire systems. Especially the more tedious parts of it. At the very least, I should be able to generate entire sub-systems.
Now that is generating code at a different scale!
Scaling code generation
The challenge is that to generate code to that scale, is that I needed to generate a wide variety of code that serve different purposes. It’s not all repeating the same thing over and over.
As an example, I need to create code to build data structures, but I need to:
- Validate that data;
- handle its states;
- write it to, and read it from a persistent store;
- display it on screen;
But then, maybe I could also generate the different tiers, database, web services, and application tiers. (early 2000, remember 🙂 ). So I need to generate a lot of code for different languages and technologies too:
- Data Definition Language (DDL)
- Structured Query Language (SQL)
- ADO .Net code, POCOs, interfaces, in C#
- Aspx pages (aspx)
- Project files (XML)
- and more…
In addition, I needed the process to be:
- Repeatable: The process can be used multiple times, and, given the same inputs, the result should always be the same.
- Predictable: The user of the system should be able to predict the results based on the input given.
- Flexible: The system should be extendable and modifiable to support a wide variety of different requirements,
To achieve this, I needed 3 things:
- Model: A set of data that describe the behaviour or functionality that I want.
- Solution: A set of instructions that process the Model to turn it into code.
- Result: The output is code that I can use, review, compile, and execute.
So I set out on this journey to create what I called, for the lack of a better name: Software Factory. I’ve spent countless hours since then working on this.
And, you know what? It works!!!
I’m currently working on the fourth version of it. Actually, 75% of version 4.0 is generated using the previous version.
It changed my workflow, changed how I write code, it event changed my vision of software.
I’ve written millions of lines of code, so I don’t have to write code anymore. It’s a bit crazy, I agree! But, in the end, it’s all about the outcome: Generating entire systems with the click of a button!