Untitled Coding Blog

I will begin this by stating clearly: you should never get to the point where you need estimate how long it will take a big task to be completed. You should never have big tasks in the first place. There are a lot of reasons why having big tasks is a seriously bad idea. Firstly, big tasks have big requirements and by the time the developer is halfway there he will most likely have forgotten parts of the requirements. A developer working on a big task needs to keep the requirement fresh inside his mind each day. Otherwise if he forgets some things he won't implement them at all. This is an issue even where I work. So extra time is wasted just refreshing those requirements. Secondly, big tasks tend to affect a lot of systems inside an application. Most developers don't know all the systems in the application so he might spend a lot of time figuring out how those systems work and how does his task affect those systems. A series of smaller tasks can be worked on in parallel and

So these past days I was kind of bored and also I wanted to prove to myself that I can take a serious software project and the understand it. I heard so many things about the CLR like it was some kind of alien technology that no one could understand. I saw that it as a challenge and decided to see if it's really like that. And the rumors were true in a way. The CLR is a marvel of software engineering. It is actually made out of multiple systems with one central system that glues them together. That central system is called the "Execution Engine". I think it's what controls and manages the execution of the program. It is for example responsible for stopping the execution of the program when the garbage collector starts to do it's job. Actually the garbage collector sends a command to the execution engine to stop the execution of the program. Yes, the garbage collector is another system just like the execution engine. It is actually pretty interesting to see how

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

Lately I realized that it would be a good idea to start writing a blog about my experiences coding various stuff or analyzing the source code of various pieces of software. So I decided to start this blog because I tend to forget what I studied over the course of the years. I feel that I missed so much not writing about these things. And surprisingly no one actually knows what I really delved into. It seems that I underestimated some of the stuff I did too, things like coding a kind of weird interpreter for C# using parts of the "Roslyn" compiler. With this blog maybe people can see what I really do and how I really think. It can also serve as a diary to show my evolution in software engineering and programming. So I hope you all enjoy reading this blog!