Creating a quick “Hello World” program will demonstrate the features of Visual Studio Express. It should now be installed in the start menu so you can launch it from there.

In Visual Studio Express, there are solutions and projects. Solutions may contain any number of projects. Each project is a collection of code files and one project can use the code from another. New projects can be started by opening the File menu and selecting New Project. A dialog box will pop up like the one pictured in Figure 4.2.

Figure 4.2. Starting a new project.

There are a number of project choices here. Windows Forms Application is a project that will make use of the forms library. A form is a .NET term for nearly all Windows GUI programs. Windows Console Application is for text-based projects. Class Library is code that’s written to be used by other projects, but it cannot be executed alone.

Hello World programs are traditionally text based so Windows Console Application is most suitable. There’s also a prompt to give the project a name; by default, this will be ConsoleApplication1. A more descriptive name, such as HelloWorld makes the purpose of the project clearer. Clicking the OK button will create the project.

Figure 4.3 shows the new project. The majority of the application is taken up by Program.cs; this is the only code file in the project. On the left is a subwindow with the title Solution Explorer. In the solution explorer is a tree of all the projects in the solution. The top level of the tree shows the HelloWorld solution we’ve just made. The only child of this tree is a project also called HelloWorld. Solutions and projects may have the same name.

Figure 4.3. The start of a brand new project.

At the very top of the Visual Studio Express window is a toolbar. In the toolbar is a small green arrow. Pressing this compiles the project and executes the code. Press it now!

A console window should pop up and then briefly disappear. This happens because the program has no code at the moment. The C# program starts its execution by calling the static Main method in the Program class. This is the place to have the program output Hello World.

namespace HelloWorld
{
  class Program
  {
    static void Main(string[] args)
    {
      System.Console.WriteLine("Hello World");
      System.Console.ReadKey();
    }
  }
}

The first line is a function call that prints Hello World to the system console. The second line waits for a keypress on the system console. If the second line wasn’t there, the program would run, display Hello World, see there’s nothing else to do, and shut down the program.

Press the green arrow and bask in the Hello World example glory (see Figure 4.4).

Figure 4.4. The Hello World program.

The results demonstrate that everything is working as expected. It is important to save this code so it can be preserved for the ages. Go to the File menu and choose Save All. This will pop up a dialog asking you where to save the file. By default, this will be in the My Documents folder under Visual Studio 2010; this is fine.

If you typed the Hello World program, you may have noticed that Visual Studio helps you out with autocomplete and drop-down boxes showing the namespaces, classes, and appropriate variables. This is some of the more obvious help Visual Studio will give. There are also some less obvious features that are worth highlighting.

Automatic Refactoring and Code Generation

Refactoring is a software development term; it means rearranging or rewriting parts of a current program to make it clearer, smaller, or more efficient, but not changing its functionality. Code generation allows Visual Studio to write some code for you. Visual Studio has a number of tools to help you; it splits them into two headings: Refactor for changing the code and Generate for automatically adding new code. There are a large number of automatic refactorings, but the following three are the ones I use most commonly.

Renaming

Namespace, class, member, field, and variable names should all be descriptive and useful. Here’s some example code that has a poor naming style.

class GameThing
{
  int _health = 10;
  int _var2 = 1;

  public void HealthUpdate(int v)
  {
     _health = _health - Math.Max(0, v - _var2);
  }
}

GameThing is a poor name unless every single thing in your game is going to have a health value. It would be better to name it GameCreature. Imagine if you were halfway through development of a large game. The GameThing class is repeated hundreds of times across many different files. If you wanted to rename the GameThing class manually, you could either hand edit all those hundreds of files or carefully use Visual Studio’s Find and Replace tool (this codebase also has many entirely unrelated classes using similar names such as GameThingManager, which the Find and Replace tool could accidentally change). Visual Studio’s refactor function can rename the GameThing class safely with only two clicks of the mouse.

Right-click GameThing. This will bring up a context menu, as shown in Figure 4.5. Choose the Refactor menu and click Rename.

Figure 4.5. The Refactor > Rename menu.

A new dialog box will appear, and the new name can be entered, as shown in Figure 4.6.

Figure 4.6. Entering a new more descriptive name.

This will now rename the class everywhere it appears in code. There are options to also rename this class in comments and strings. The same process can be done for the function and variable names, resulting in something like this.

class GameCreature
{
  int _health = 10;
  int _armor = 1;

  public void TakeDamage(int damage)
  {
    _health = _health - Math.Max(0, damage - _armor);
  }
}

Far more understandable!

Creating Functions

Often when writing a section of code, a function that’s not been written yet is needed. The generate tools in Visual Studio let you write your code as if the function did exist, and then automatically create it. As an example, let’s take an update loop for a player class.

class Player
{
  public void Update(float timeSinceLastFrame)
  {

  }
}

In the update loop, the player animation needs to be updated. It’s best to do this in a separate function, and that new function would look something like this.

class Player
{
  public void Update(float timeSinceLastFrame)
  {
    UpdateAnimation(timeSinceLastFrame);
  }
}

This function doesn’t exist yet. Instead of writing it all out manually, the generate functions can do it (see Figure 4.7).

Figure 4.7. Refactor menu for creating a function.

Right-click the function name and choose Generate > Method Stub. The following code will be created in the Player class.

private void UpdateAnimation(float timeSinceLastFrame)
{
  throw new NotImplementedException();
}

All of this was created automatically without any manual typing. The function has an exception saying no code has been written yet. Calling this function in a program will cause the exception to be thrown. After writing code for the function, that exception can simply be deleted.

Separating Chunks of Code

It’s quite common in large programming projects for one area to get bloated. An update loop for a common object such as the player may become hundreds of lines long. If this happens, it’s a good idea to break out some of that code into separate functions. Let’s consider the game world’s update loop.

class World
{
  bool _playerHasWonGame = false;
  public void Update()
  {
    Entity player = FindEntity("Player");

    UpdateGameCreatures();
    UpdatePlayer(player);
    UpdateEnvironment();
    UpdateEffects();

    Entity goldenEagle = FindEntity("GoldenEagle");

    if (player.Inventory.Contains(goldenEagle))
    {
      _playerHasWonGame = true;
      ChangeGameState("PlayerWinState");
    }
  }

  // additional code
}

This loop isn’t that bad, but the last piece of code looks a little untidy; it could be moved into a separate function. To do this automatically, select the code as if about to copy and paste it. Start the selection from the line Entity goldenEagle... to the closing brace of the if-statement. Now right-click.

The context menu will come up as in Figure 4.8; select Refactor, and then choose Extract Method. You will be prompted to name the method. I chose CheckForGameOver. The selected code will then be removed and placed in a new function; any variables that it uses will be passed in as arguments to the newly created function. After the refactor, the code will look like the following:

Figure 4.8. Refactor menu for extracting a function.

bool _playerHasWonGame = false;
public void Update()
{
  Entity player = FindEntity("Player");

  UpdateGameCreatures();
  UpdatePlayer(player);
  UpdateEnvironment();
  UpdateEffects();

  CheckForGameOver(player);
}

private void CheckForGameOver(Entity player)
{
  Entity goldenEagle = FindEntity("GoldenEagle");

  if (player.Inventory.Contains(goldenEagle))
  {
    _playerHasWonGame = true;
    ChangeGameState("PlayerWinState");
  }
}

The world update function is now shorter and more readable.

It’s worth investigating and becoming familiar with the refactor functions as they can be excellent time savers.

The official website for TortoiseSVN is http://tortoisesvn.net/, and the latest build should be available to download from http://tortoisesvn.net/downloads/. It’s also available on the CD. There are two versions x86 and x64; these are for 32-bit machines and 64-bit machines, respectively.

Installation is simple, just double-click the icon and accept all the default options. This will install the program to your program files directory. After installation has finished, you will be prompted to restart.

Once your system has restarted, right-click on your desktop. You should have three extra items in your context menu, as can be seen in Figure 4.9. These menu items will be used to manage your source code.

Figure 4.9. SVN context menu.

A source control repository is the place where all the code and data will be stored. We’ll make our repository on the hard disk. It’s a good idea to choose a location that will be easy to backup. Somewhere like My Documents is a good place. Think of the repository like a safe that’s going to look after all the code written from now on.

Once you’ve decided where you want the repository to be, create a new directory. All the source control files will go in here. You can name the directory whatever you want. I named mine, “MyCode”. Open the folder and right-click. The context menu will appear; choose the menu item labeled Tortoise SVN. This will give some more options, as shown in Figure 4.10; choose Create Repository here.

Figure 4.10. Using the context menu to create a repository.

Some new files will appear in the directory, as shown in Figure 4.11.

Figure 4.11. Files in the repository.

Congratulations! You’ve just made your first source code repository. Let’s have a look inside! Go up to the parent directory. Now right-click on the directory containing your repository. This time choose SVN Repo-browser. This brings up a dialog, but it’s empty. That’s because there is nothing in the repository—not yet anyway. In time, you’ll fill this up with all your great coding ideas and projects.

Remember the Hello World project? That’s some pretty important code and should be put under source control so that it can be kept safe. If you saved the project to the default directory, it will be in C:UsersYourUserNameDocumentsVisual Studio 2010Projects on Windows 7 and Vista and C:Documents and SettingsYourUserNameMy DocumentsVisual Studio 2010Projects for XP.

Now, go to the directory with your source control repository and explore the repository as before. Right-click on the right-most window and a context menu will appear. Choose Create Folder and name it HelloWorld.

In the projects directory, right-click on the HelloWorld folder and choose SVN Checkout. This will bring up a dialog box with a text box labeled URL of Repository; this should have your repository path in it. If it doesn’t, click on the folder icon, browse to your repository folder, and select it. Click OK. The dialog box will change and show a single directory called HelloWorld. Select that directory. The check out directory text box should read something like C:Users YourUserNameDocumentsVisual Studio 2010ProjectsHelloWorld for Windows 7 and Vista and C:Documents and SettingsYourUserNameMy DocumentsVisual Studio 2010ProjectsHelloWorld for XP.

At the moment, the repository is empty; all it has in it is the empty Hello World directory that was just created. The next step is checking out this empty directory into the same place as the Hello World project. In the checkout window, click OK. This will check out the repository in the same place that the code currently is. Figure 4.12 shows inside the Hello World directory, and the changes that have occurred.

Figure 4.12. The checked out HelloWorld project.

All the files now have small question mark icons. These indicate that the files have not been added to the source control repository but they’re in the checked out directory. There’s also a hidden folder called .svn. This hidden folder contains the information that SVN uses to manage itself.

The next step is to add all the important code files into the HelloWorld repository. HelloWorld.sln is important; it’s the file that says how the solution is set up and what projects are included.

Right-click on HelloWorld.sln, click TortoiseSVN > Add (shown in Figure 4.13), refresh the directory, and a plus sign will appear next to HelloWorld.sln, as shown in Figure 4.14. HelloWorld.sln has been added to the repository. First, let’s add the rest of the files. There’s a directory called HelloWorld; this is the project directory. Right-click on it and choose Add, the same way we did for HelloWorld.sln.

Figure 4.13. Adding to the repository.

Figure 4.14. Plus sign to indicate files are to be added to source control.

This will bring up a list of all the files in the directory. Unselect all the files and type the following.

HelloWorld/
HelloWorld/HelloWorld.csproj
HelloWorld/Program.cs
HelloWorld/Properties
HelloWorld/Properties/AssemblyInfo.cs

These are the files we’ll be editing. The other files are automatically generated so there’s no need to add them to source control. Once the files are selected, they’re ready to commit. Committing copies the new files from your local check out and adds them to the source repository.

The easiest way to do a check in is to open your projects folder, right-click on the HelloWorld folder and choose SVN Commit.

This brings up a dialog listing all the files to commit. There is also a comment box for the commit. It’s good practice to always add a comment about what changes have been made. In this case, we’re adding a new project, so it’s fine to list the comment as “First commit of hello world project.” Press commit and the code is committed.

The code is now safe in the repository. Let’s test it! Delete the HelloWorld folder, or if you’re a little less trusting, rename it to HelloWorld. Now right-click and select SVN Checkout. The HelloWorld project should be selected; click OK. You’ll notice a new directory has appeared titled HelloWorld. Enter the directory and double-click the brand new HelloWorld.sln icon. This will launch Visual Studio; pressing the green arrow will cause the Hello World program to compile and run perfectly.

When working with a team, everyone can check out the project and all start working on it.

One of the nice things about source control is that it allows you to look back on the project and see how it’s evolved. Right-clicking on the Hello World project directory and selecting SVN Show Log will pop up the history dialog. This shows all commits with your high-quality descriptive comments (see Figure 4.16).

Figure 4.15. Committing source code.

Figure 4.16. Viewing the history.

So far, the history view shows only two commits. The first is the creation of the project, and then the second when the files were added. Play around with the history options. The statistics button gives graphs and information about the commits. It also reports who committed what. This is very useful when working in a team.

Open up Visual Studio and edit the Hello World program to look like the following.

public static void Main(string[] args)
{
  System.Console.WriteLine("Let's make some games.");
  System.Console.ReadKey();
}

The program is developing nicely. We don’t want to lose these changes so we had better do one more commit. Return to the Hello World project directory and select SVN Commit again. Program.cs will come up as modified. Add a useful comment such as “Changed hello world text” and click OK. Now the code and source control are both up to date.

With that commit, another feature of SVN can be introduced. Open the history window again by going to SVN Show Log. Click on the most recent commit, revision number three. In the third dialog window, you’ll see the modified /HelloWorld/HelloWorld/Program.cs file. Right-click on this and choose Show Changes, as shown in Figure 4.17.

Figure 4.17. How to compare changes.

This will bring up a new program called TortoiseMerge. TortoiseMerge will display two files at once: the current commit and the previous commit, as is shown in Figure 4.18. In the previous commit, Hello World is crossed out and highlighted in red; this means it’s the area of code that’s changed and the text has been removed. In the current commit, we can see that it has changed to “Let’s make some games.”

Figure 4.18. Using the merge tool to compare.

This merge tool is very useful for seeing how code has changed.

NUnit is very simple to use, but before writing tests, a project is needed. In Visual Studio, start a new project by selecting File > New Project as shown in Figure 4.20. Once again, choose a Console Application project and call it PlayerTest.

Figure 4.20. Adding a class in Visual Studio.

This will create a default project with one file named Program.cs. Right-click on the project and select Add > Class, as shown in Figure 4.20. This will be the player class.

This brings up a dialog box with a number of preset class types from which to choose, shown in Figure 4.21. The one needed here is simply a class, so choose that and name it Player.cs. A separate class will also be needed for the tests; add another class the same way, but call it TestPlayer.cs.

Figure 4.21. Naming a class in Visual Studio.

To use NUnit, it needs to be added to the project as a reference. In the Solution Explorer, right-click on the References node and select Add Reference, as shown in Figure 4.22.

Figure 4.22. Adding a reference.

This will bring up a very large list of references. The reference that needs to be added is NUnit.Framework. Once the reference has been added, it can be used by adding a using statement. In TestPlayer at the top of the file, there are a number of statements starting with “using ...”. To use NUnit, an extra line must be added using NUnit.Framework;. Then a simple test can be added.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using NUnit.Framework;

namespace PlayerTest
{
  [TestFixture]
  public class TestPlayer

  {
    [Test]
    public void BasicTest()
    {
     Assert.That(true);
    }
  }
}

The first things to notice in this code snippet are the attributes. In C#, an attribute is a bit of metadata—some descriptive information about a class, function, or variable that can be accessed programmatically. Attributes are surrounded by square brackets. Here the class has an attribute of type TestFixture. In NUnit terminology, a test fixture is a group of related unit tests. The TestFixture attribute is used to tell NUnit that the class TestPlayer will have a number of tests in it.

The second attribute is on the function BasicTest. This is a test attribute, which means the function BasicTest is a test that needs to be run. As the Player code is written, more of these small test functions will be added to the TestPlayer class.

Make sure the code compiles by pressing the green arrow or by pressing F5. A console window will flash briefly, and then quickly disappear again. This behavior is fine for now.

NUnit has a special GUI program for running tests. NUnit GUI is found in the Start menu. Once run, it looks like Figure 4.23.

Figure 4.23. NUnit GUI on startup.

NUnit works on compiled code. Visual Studio compiles the code every time the green arrow or F5 is pressed. The compiled code is stored in the project directory (normally, ProjectsPlayerTestPlayerTestin(Debug/Release)). The default location for the projects directory is in the MyDocuments directory under Visual Studio 2010.

In here, you will find an exe file. This is the compiled version of the code. There is also an nunit.framework.dll file; this is the NUnit reference that was included earlier. The exe file won’t be able to run without this dll.

To run the tests, select File > Open Project in the NUnit GUI. Navigate to the compiled code in the release directory. Click on the PlayerTest.exe file. This will load the test we wrote earlier in NUnit, as shown in Figure 4.24.

Figure 4.24. NUnit GUI loading the project.

Click the Run button; the project tree should turn green and a tick will appear next to BasicTest. This means the test ran successfully. If the code is changed so that the test fails, the little green circles will turn red. Try changing the code to fail then running the tests again.

The player class in the game must represent the concept that if the player eats a mushroom, he gets bigger. It’s assumed all players begin life small. That will be the first test.

namespace PlayerTest
{
  [TestFixture]
  public class TestPlayer
  {
    [Test]
    public void BasicTest()
    {
      Assert.That(true);
    }

    [Test]
    public void StartsLifeSmall()
    {
      Player player = new Player();
      Assert.False(player.IsEnlarged());
    }
  }
}

The Assert class is part of NUnit and is the workhorse of writing the unit tests. The function IsEnlarged does not exist yet. Using the refactor tools, Visual Studio can automatically create this function. This will result in the following code in the Player class.

class Player
{
  internal bool IsEnlarged()
  {
    throw new NotImplementedException();
  }
}

Running the unit test in NUnit now will result in a failure with the following error message

PlayerTest.TestPlayer.StartsLifeSmall:
System.NotImplementedException : The method or operation is not
implemented.

The test fails because one of the methods in the Player class hasn’t been implemented yet. That can be solved by adding the functionality.

class Player
{
   bool _enlarged = false;
   internal bool IsEnlarged()
   {
     return _enlarged;
   }
}

It will now pass the test. Build the project, run NUnit again, and a green circle will appear next to the project. The next test is for eating a mushroom. Here’s the test.

namespace PlayerTest
{
  [TestFixture]
  public class TestPlayer
  {
    [Test]
    public void BasicTest()
    {
      Assert.That(true);
    }

    [Test]
    public void StartsLifeSmall()
    {
      Player player = new Player();
      Assert.False(player.IsEnlarged());
    }

    [Test]
    public void MushroomEnlargesPlayer()
    {
      Player player = new Player();
      player.Eat("mushroom");
      Assert.True(player.IsEnlarged());
    }
  }
}

This new test has a pleasing symmetry with the previous test. As tests are built up, they form living documentation for the project. Someone new to the code can read all the tests associated with a certain function and get a very good idea about what it’s supposed to do.

Like the previous test, additional functionality has been added. The player does not yet have an Eat method. Like the previous example, Visual Studio’s refactor tools can quickly generate the required method.

class Player
{
  bool _enlarged = false;
  internal bool IsEnlarged()
  {
    return _enlarged;
  }

  internal void Eat(string p)
  {
    throw new NotImplementedException();
  }
}

The new test will now fail if NUnit is run. The test can be made to pass with the following code.

class Player
{
  bool _enlarged = false;
  internal bool IsEnlarged()
  {
    return _enlarged;
  }

  internal void Eat(string thingToEat)
  {
    if (thingToEat == "mushroom")
    {
     _enlarged = true;
    }
  }
}

All the tests pass, proving this code is correct and working as desired. That’s basically it for unit testing. It’s not a very complicated technique, but it does give the writer faith in the code and the ability to change it without breaking functionality.