Gonzo blogging from the Annie Leibovitz of the software development world.

Category: Programming (Page 1 of 4)

Useless Comments in Code

I’m always pleased when I see developers commenting code. It means there’s something there that should be commented so the next guy will know WTF whoever wrote it was thinking. However much like any FOX special, there are times when “Comments Gone Wild”. I present some production code that contains some more, err, useful comments that I’ve found.

// Returns: Position of the divider

// Summary: Call this method to get the position of the divider.

int GetDividerPos();


Hmmm. Glad that was cleared up.

// Summary: Call this method to refresh items in the list.

void Refresh();


Again. Good to know.

// Summary: Call this method to remove all items in the list.

void RemoveAllItems();


Whew. For a minute there I thought we would have to spend some serious debugging time hunting down this method.

And my personal favorite…

/* this next part does something cool; don't even try to understand it*/

while(i_love_lucy_is_on_tv)

{

   xqtc_fn();

}


(i_love_lucy_is_on_tv turned out to be a boolean variable set to false). Go figure.

Just can’t have enough zombie games

I´ve been struggling with an idea for a game for sometime now (I´ve been writing tools for so long it´s time to actually write a commercial game). I think I figured out my concept with a game I call “Risen”.

It´s a zombie game and works in three modes. Single Player, Co-op, and Multiplayer. They all work pretty much the same, just scaled up based on the number of people in the game.

The game takes place in a world where the dead have taken over. Typical zombie action as they roam aimlessly looking for brains to eat. Each part of the cityscape (and countryside) is divided up into zones (several city blocks, not sure what the engine can handle yet, using Torque so size shouldn´t be a problem). Within that zone there are three types of entities.

Pedestrians:

These are NPCs that run around doing daily stuff, but mostly running from zombies (depending on the level of zombie infestation in that area)

Zombies:

The villians (or heroes depending on how you look at it) of the game. They run around looking for brains to eat and growing stronger.

Players:

Your mission. Kill or be killed.

The Game:

Zombies wander around eating pedestrians (and players). Each time a zombie munches down on a ped, it grows in strength. Zombies also do some flocking so if they see another zombie they´ll wander together for awhile, forming a zombie mob which will attack in groups. When a zombie eats someone, they infect their victims and they in turn become the walking undead.

The players goal is to erradicate all the zombies on a level to move to the next block. Players themselves can be attacked and will become zombified. Here´s where the game gets interesting where the player now plays as a zombie. Rather than having the goal of blowing away the undead, the player now must hunt out peds (and other players) to eat in order to survive. The level ends when all zombies are erradicated or all players become zombies (whichever comes first). There are scores for both (zombies and player/zombies including how many ped/players were turned, brains eaten, etc.).

Players have weapons but generally have to find them within the game (and utilizing a broomstick or leg of a chair works, but not very effective). There are various archetypes that players can pick from. These include soldiers, scientists, jocks, reporters, etc. each with their own advantages/disadvantages.

Zombies only come in zombie flavour and have no weapons to speak of. They do gain abilities (like being able to spit/vomit zombie goo on players) as they grow in strength. Each time they go munching they also grow in endurance, stamina, etc. so dropping a zombie that´s consumed the football team will be quite a feat and probably require multiple players working together.

Feel free to label me a crackpot, rank me as a genuius or pay me gobs of cash to build this idea for you.

Multiple inheritance in C#

Can you inherit from multiple classes in C#? No, the language doesn’t support it however there are ways around it.

From a design perspective you have to ask yourself, Will a Class fully represent an object? Meaning that, if we have a base class with abstract methods designed for a particular application and we know that the inheriting object will only need the methods defined in that class. We now have a valid design pattern here.

The Vehicle Car Object

Lets say we have an abstract class called “Vehicle” as well as another class called “ConstructionVehicle”. The vehicle class has methods such as Accelerate() , Stop(), and the “ConstructionVehicle” class has methods such as ExecuteDump() and TurnOnBackUpSound(). If we were only going to build a Car object and know we would only use those methods from the “Automobile” class this would be fine.

The DumpTruck Object

Now we want to create another object called “DumpTruck”. We could inherit from the Automobile class but that class does not have the methods that we need called ExecuteDump() and TurnOnBackUpSound(). If we were using a language such as C++ we could easily inherit from both classes using multiple inheritance. However, seeing C# is our language of choice, multiple inheritance is not an option, you may only inherit from one Base Class.

From Abstract Classes to Interfaces

From a design perspective we must choose a different design. C# supports what is called “Multiple Implementation”, which is to says a class can implement more than one interface. Our design now changes the “Vehicle” class and the “ConstructionVehicle” class into interfaces. Below we have

defined the two interfaces with their very simplistic methods:

interface IConstructionVehicle

{

  void ExecuteDump();

  void TurnOnBackUpSound();

}

interface IVehicle

{

  void Accelerate();

  void Stop();

  void TurnOnBackUpSound();

}

If we built a class that inherited from these two interfaces we would be able to do so spanning multiple inherited interfaces. Design problem solved!

Or is it?

Explicit Interface Implementation

If you look at both interfaces defined above you’ll notice that they share in common a method of the same name “TurnOnBackUpSound()”. Problem? No, in fact C# supports what is known as “Explicit Interface Implementation”, which allows the programmer to specify which member of

which interface they want to use. Putting the Interface name in front of the member name allows this to happen as shown below.

public class DumpTruck: IEngine, IBody

{

  void IEngine.Test()

  {

    Console.WriteLine("This is the Engine TEst");

  }

  void IBody.Test()

  {

    Console.WriteLine("This is the Body TEst");

  }

}

Implementation Hiding

Another benefit to this technique is something called “Implementation Hiding”. Implementation Hiding allows the methods from the implemented interface to be hidden from the derived class unless the developer explicitly calls the interface. This technique obviously reduces the clutter for a developer.

From a theoratical point of view MI has it’s place. In many situations we need to make a decision whether to define an interface or an abstract class with same signatures. An interface and abstract class are exactly the samething except abstract class would allow some non-abstract members which can act as shared common code plus it can have protected overridable members. If MI is not supported then I have to really think whether to put my signatures in interface or an abstract class and decision would be based on limited knowledge whether client classes could have been already been derived from other class.

Microsoft says:

1. The number of places where MI is truly appropriate is actually quite small. In many cases, multiple interface inheritance can get the job done instead. In other cases, you may be able to use encapsulation and delegation.

2. Multiple implementation inheritance injects a lot of complexity into the implementation. This complexity impacts casting, layout, dispatch, field access, serialization, identity comparisons, verifiability, reflection, generics, and probably lots of other places.

So in nutshell, there’s no simple answer. If there is no MI, your ability to share common code along with abstract members might be limited but you might want to first consider refactoring your code and design before blaming the limitations of a language.

VS.NET and the Microsoft Way…

I’ve been struggling with a “best practice” around setting up larger scale projects with .NET

The Web Project wizard in Visual Studio .NET is convenient for creating quick ASP.NET applications on your local machine, but in an effort to simplify your life, it also makes many decisions for you that are difficult to change if you need more flexibility. If you don’t create the virtual directory first then the wizard will automagically create on for you, based on the root of your web server (which is normally C:InetPubwwwroot). My biggest pet peeve with Web Projects is that you cannot even open a .sln file if the virtual directory mapping in IIS is not set up correctly. This becomes a problem with you have multiple users all trying to open the projects you’ve created.

One fix is to not share solution files, but when it comes to the ASP.NET applications, you always have to have the virtual directory setup first before you can open a web project. It’s all very frustrating and I still can’t find a good middle-ground between what you can do without shooting yourself in the head and having a well structured project directory layout. Microsoft has an article where they basically tell you to setup your physical directory first, then point a virtual to it, then create the ASP.NET project. I find this is the fasted way to open up a project as well, because VS.NET isn’t churning in the background creating the virtual directories.

There are some other tricks with folder structure because you can easily create a localized breadcrumb navigation trail with ASP.NET (there are several components out there) which is based on the directory structure. With UrlRewriting, you can direct the user all over the place and not worry about moving things internally. I think this is one the big downfalls with HTML and the Web. You move a link and your entire system falls apart. Some content managment systems (like Microsoft’s own CMS) fix this by storing everything in a SQL database and referring to the files through GUID like URLs, but a) it starts to look like Lotus Notes after awhile (if you’ve ever saw those Urls, they’re god awful ugly and long) and b) it still doesn’t really protect you and moving or changing something sometimes breaks things. There’s still some work there before that problem gets solved.

I think (and correct me if I’m wrong here) it should start with a Web project. The sequence that seems to have worked for me is this:

1. Create a physical directory (I refuse to call them folders) on the hard drive to hold the project

2. Create a web subfolder in this directory. This is where your web app will live.

3. Create a virtual directory to point to the directory you created in step #2 with your app name

3. Create a new Web application in VS.NET with that name. VS.NET will automatically save all your files to the physical directory you created in step 2

4. Create new class library projects and add them to the solution (for unit testing, data access, business functions, etc.) and put them somewhere in the structure (maybe a test or src folder off the root)

One trick I picked up this week (thanks to the guys at ThoughtWorks and some cool guys at CP) is to create one class library project called Core for all your system functions. Inside this project, create a folder called DAL, DTO, Domain, etc. to hold the classes for such. This way you can import one namespace into your tests and it makes it easy to reference everything else. Of course if you have to physically split some of the pieces (like the data access layer from your domain) this might be a problem. I’ve always put my DAL and Domain into separate projects. Not sure if that will be a problem with this setup but it does make things easier in the end.

I don’t think there’s any one real solution or “right” way to do things here. A rule of thumb might be to group logical sub-sections of your application in their own directories. If you ever have more than 10-15 files in one directory, maybe it’s a sign you need to improve your directory structure.

In the end, there is also motivation to have all directory structures the same on all developer machines, as well as having the same structure mirrored on an integration server (like one running your web server or Continuous Integration one). Makes for a simple migration from one environment to the next. Don’t even get me started on the whole namespace heiarchy…

« Older posts