Skip to main content

Part 1 of writting an experimental code analyzer and sort of interpreter for C#

The purpose of this C# analyzer is to see all possible execution paths from any entry point inside the code. Currently the entry point can be only a method.

There are multiple ways to deal with this. The approach would be to rewrite all existing code and rewrite all conditional statement so that they are true all the time. This approach has numerous disadvantages.

Firstly, it will actually execute the code and any calls to external resources such as databases will be executed. Since the code has been altered, there is also no guarantee that it won't produce exceptions at runtime. And for really big code bases, it will be incredibly slow and it will require actual compilation of the modified code which may take even more time.

My approach is to write a C# interpreter with some special conditions that will go through all possible execution paths. In order to go through all the execution paths, our interpreter will need to ignore all the conditional statements and jump directly in the code that is executed when a given statement is true.

Still this is not enough, for example if we have an "if" statement and in each branch of it we assign a new variable to the same reference, then what should happen? If we overwrite the value of that reference each time we assign something to it, then if someone calls a method on that reference, it might ignore some methods of the variables that were previously replaced. So we need to modify the reference assignment behavior and the actual references themselves. The references in the code become collections of variables and when we assign a new value to it, we add another variable inside the collection.

So a variable or better said reference in our interpreter will look like this:



























Since now a reference contains multiple variables, the way we call methods is also changed.
If we have multiple variables inside a reference, what methods do we call? We actually need to call the method on all the variables contained in that reference.


Above is just a part of the code, but we can see that iterate through all the variables that are stored in the reference, get the accessed method and then call the method with the variable. All methods by default have an extra parameter to them, the object on which the method is called. This parameter is passed on the last line of the code above. Inside the method call it will become the "this" variable.

Comments

Popular posts from this blog

Some software development common sense ideas

 I haven't really written here in a long time so it's time to write some new things. These are just some random common sense things that seemed to short to write about individually but seem really interesting and useful to me or other people 1. There is nothing fixed in software development, all things vary by circumstances and time Remember the documentation that didn't seem that important when you started the project, well after a couple of years one the application has grown and become really complicated, no one actually knows everything about the application anymore. So now you really need that documentation. What happens if you suddenly need much more people to develop the application because of some explosive growth? Without documentation, new developers will just look at the application like they look at a painting. This actually happened to me. Maybe in the beginning of a project, a technology really helped you a lot but as the project grew, it started making things...

My thoughts as an experienced developer in this field.

To be honest, I would have never guessed that      I would end up saying these these things, especially jn the beginning of my career. As you become more experienced, you kind of get to see everything and you become less impressed by new things. Honestly there is some sort of repetitiveness in this field and we kind of like to reinvent the wheel quite often, because well, we become a bit too easily bored. Take for example how the web looks now, a lot of it has been borrowed from other places, mostly desktop development, especially the parts about making custom reusable components.  Or from older frameworks, like state management in the UI which actually was first properly implemented in Asp .Net Webforms, as far as I know, something like 20 years ago, where you used to have the dreaded view state.  But most likely something similar existed before that too. I was not that surprised when React adopted initially this idea. Or even less surprised when hooks where in...

My experience joining Microsoft, one of the leading companies in the industry

 This past year I finally made a big leap in my career and joined on of the leading companies in this the software industry, it's been one of my lifelong dream to join such a company and now it happened. It's been quite a journey and I noticed a lot of things so far that I would have never imagined.  Firstly, the scale of things is something that completely blows my mind. I never thought that I would be part of tens of teams, just in my local division in geographical region. Everything is massive and scattered around the globe with hundreds of teams out there. And getting so many teams to work together is really a challenge, especially making sure that they don't constantly reinvent the wheel.  Or another very challenging aspect is the fact that no team is actually alone and depends on the work of many others teams. Here I noticed several skills that are really useful which I never though of before. One of the skills is getting the right information and reaching the...