My great friend and co-worker posted a comment tonight asking when I would finish The Quest and post it for all to see. Well, I have been sitting on it for a while. There are some bugs and I moved on in the book thinking I would go back and fix the bugs. Overall, the game works. Some places it is easier for the player and other parts are harder for the player.
I believe I can find out why I have bugs and how to fix them, it is just about finding and taking the time to debug and fix it. Lately, I have been taking on bugs at work and debugging which has given me great experience on what debugging looks like. While fixing the bugs I have learned pieces of C# and .Net that the book hasn't talked about yet.
One example is that while testing and fixing bugs in our API I have learned how to use LINQ statements. In the book this aren't mentioned until chapter 15. By the way, I am now in chapter 10 which is further then I got before in the book. It is amazing how much LINQ statements help. I understand at the surface, but will save trying to describe them until chapter 15.
Chapter 9 talks a lot about streams and how to interact with files within a program. When you are using streams make sure to close the stream or you may lock the file. That can cause problems. Hey! There is a great way around having to remember closing the stream. You can wrap your stream in a using statement. (These are different from the using directives at the top of your files).
You have a lot of If/Else statements? There is an easier way to do this! Use a switch statement. Switch statements provide a mechanism for writing the variable to check once and then say what to do with each different possible output of that variable. Switch simple example:
I also learned about serializing and deserializing your files. Serializing is like flattening your output so it can be desearialized (reanimated) later. Opening a serialized file and trying to read it is...well...impossible for me. It writes it in Binary. Actually, just write a stream reader that deserializes the file and there you go!
I ran into a collision of work and my book while reading chapter 9. At work last week, I was debugging an issue and my team lead asked if I knew what an attribute was. Deer in the headlights. Okay, not really, I did fess up and said I wasn't sure what those were. So, Ben described them to me and walked through the example in the code that we were seeing the issue. A few days later that exact topic came up! Dear Headfirst C#, I actually already knew this before reading! I felt knowledgeable! I may feel that way when I get to chapter 15 too!
Chapter 10, exceptions. I have only read the first couple pages, so not much to report here.
Brett, here is the buggy game The Quest. The github repo is located on my general github.
Hey if you need an excuse manager for work on why you can't come in, chapter 9 has you create an excuse manager so you can remember what worked with your boss and when you last used it. Get your very own excuse manager here!
Sorry for the long read. No excuses, they never go well with the readers...
It is better to offer no excuse than a bad one. - George Washington
I believe I can find out why I have bugs and how to fix them, it is just about finding and taking the time to debug and fix it. Lately, I have been taking on bugs at work and debugging which has given me great experience on what debugging looks like. While fixing the bugs I have learned pieces of C# and .Net that the book hasn't talked about yet.
One example is that while testing and fixing bugs in our API I have learned how to use LINQ statements. In the book this aren't mentioned until chapter 15. By the way, I am now in chapter 10 which is further then I got before in the book. It is amazing how much LINQ statements help. I understand at the surface, but will save trying to describe them until chapter 15.
Chapter 9 talks a lot about streams and how to interact with files within a program. When you are using streams make sure to close the stream or you may lock the file. That can cause problems. Hey! There is a great way around having to remember closing the stream. You can wrap your stream in a using statement. (These are different from the using directives at the top of your files).
You have a lot of If/Else statements? There is an easier way to do this! Use a switch statement. Switch statements provide a mechanism for writing the variable to check once and then say what to do with each different possible output of that variable. Switch simple example:
switch(variabe)
{
case enum.value:
//
code to happen
break;
case enum.value2:
//
code to happen
break;
default;
//
code to happen. Case statements can have the default case which will apply if
none of the other cases apply.
break;
}
I also learned about serializing and deserializing your files. Serializing is like flattening your output so it can be desearialized (reanimated) later. Opening a serialized file and trying to read it is...well...impossible for me. It writes it in Binary. Actually, just write a stream reader that deserializes the file and there you go!
I ran into a collision of work and my book while reading chapter 9. At work last week, I was debugging an issue and my team lead asked if I knew what an attribute was. Deer in the headlights. Okay, not really, I did fess up and said I wasn't sure what those were. So, Ben described them to me and walked through the example in the code that we were seeing the issue. A few days later that exact topic came up! Dear Headfirst C#, I actually already knew this before reading! I felt knowledgeable! I may feel that way when I get to chapter 15 too!
Chapter 10, exceptions. I have only read the first couple pages, so not much to report here.
Brett, here is the buggy game The Quest. The github repo is located on my general github.
Hey if you need an excuse manager for work on why you can't come in, chapter 9 has you create an excuse manager so you can remember what worked with your boss and when you last used it. Get your very own excuse manager here!
Sorry for the long read. No excuses, they never go well with the readers...
It is better to offer no excuse than a bad one. - George Washington
