Basternae.org

Zone data encapsulation is complete now.  It was a long, tedious process, but it’s all for the greater good.

Last time the code was Fx-Copped, It ran 778,249 checks and found 10,850 issues.  This time, it ran 865,441 checks and found 10,370 issues.  It’s an improvement, but not a huge one.

We now have the power to enforce sanity.  For instance, when an object’s condition is set, we cap it at a max of 100% (perfect) and a minimum of 0% (destroyed).

Just a progress report — things are moving along slowly but steadily and it shouldn’t take all that much longer to finish data encapsulation for the zone data classes.

I ran FxCop against the Basternae source for the first time today. It ran 778,249 checks and found 10,850 issues.

While some of these really are design flaws, some minor and some serious, many of them are not applicable to this project, such as the security declarations and assembly signing. Here’s how I break down what FxCop has complained about:

Applicable issues:
* Array fields should not be read only.
* Avoid type names in parameters.
* Avoid uncalled private code.
* Avoid unnecessary string creation.
* Collections should implement generic interface.
* Consider passing base types as parameters.
* Do not cast unnecessarily.
* Do not concatenate strings inside loops.
* Do not declare visible instance fields. (This is what the encapsulation I’m working on is all about, and was a significant percentage of what FxCop complained about.)
* Do not initialize unnecessarily.
* Do not name enum values ‘Reserved’. (This was a surprise.)
* Do not pass types by reference.
* Do not raise reserved exception types.
* Enums should have a zero value.
* Flags enums should have plural names. (Dang, this one is pretty nitpicky.)
* ICollection implementations have strongly typed members.
* Identifiers should be cased correctly. (Yes, it actually complains about that, and there were a lot found.)
* Identifiers should have correct suffix.
* Identifiers should not have incorrect suffix.
* Identifiers should not match keywords. (Alias, Object, Event, and Exit classes.)
* Implement standard exception constructors.
* Interface methods should be callable by child types.
* Lists are strongly typed.
* Mark all non-serializable fields.
* Mark assemblies with assembly version (Been doing this, but missed one.)
* Mark ISerializable types with serializable. (Fixed these immediately. Duh.)
* Mark members as static. (It’s not the right solution for the ones FxCop found, but there are problems with what it found.)
* Nested types should not be visible.
* Non-constant fields should not be visible. (Encapsulation again.)
* Operations should not overflow.
* Operator overloads have named alternatives.
* Override equals and operator equals on value types.
* Provide correct arguments to formatting methods.
* Remove empty finalizers.
* Remove unused locals.
* Rethrow to preserve stack details.
* Review visible event handlers.
* Static holder types should not have constructors.
* Test for empty strings using string length.
* Type names should not match namespaces.
* Types that own disposable fields should be disposable.
* Use properties where appropriate.
* Validate arguments of public methods. (Note that FxCop does not appear to be Contract-aware, so some of these will be non-issues.)

Non-applicable issues found:
* Assemblies should declare minimum security.
* Assemblies should have valid strong names.
* Mark assemblies with CLSCompliant.
* Mark assemblies with ComVisible.
* Specify CultureInfo. (This is not an internationalized application.)
* Specifiy IFormatProvider. (Yet again, not an internationalized application.)
* Specify MessageBoxOptions. (This refers to right-to-left reading language support, also not applicable.)

Issues I don’t agree with:
* Do not catch general exception types. (Sometimes it really is the simplest and best solution.)
* Do not declare read only mutable reference types.
* Do not expose generic lists.
* Do not pass literals as localized parameters. Use a resource table instead.
* Identifiers should be spelled correctly. (FxCop didn’t like my use of “x” and “y” as variables in a coordinate class.)
* Identifiers should not contain underscores. (There are a ton of these, about 30% of the Cop’s finds. Pretty much all of our flags are named using underscores.)
* Long acronyms should be Pascal-cased. (Side effects of the previous issue.)
* Only FlagsAttribute enums should have plural names. (Stop whining about names already!)
* Prefer jagged arrays over multidimensional. (No. There’s a specific reason for multidimensional arrays.)
* Short acronyms should be uppercase.
* Used preferred terms.

So yes, there are quite a few things to be fixed. I’m not going to spend any extra effort on that right now — some of these problems will resolve themselves as part of the in-progress changes. Even so, it’s nice to be aware of what doesn’t match preferred style, even if it accomplishes nothing other than having a solid knowledge of which rules are being broken on purpose. I’m sure I’ll post updates on FxCop stats as the code evolves.

You have passed the halfway point and are nearing your next codebase.

There’s a lot to do, but I’m halfway through encapsulating all of the data for the zone classes.  This will give us the power to validate data before assigning it to a variable and will help us reduce the number of boundary checks in the code by moving them to the property we’re trying to set.  End result:  code that’s easier to maintain and modify.

I love the refactoring support in MS Visual Studio.  It makes certain things like field encapsulation incredibly easy.

For instance, thanks to its origins in C, most of the Basternae 3 codebase doesn’t have encapsulation yet.  This means that there are tons of class member variables declared like this:

public string _keyword;

Setting the _keyword member variable to private and creating a property named Keyword with getters and setters that reference the _keyword variable would take about 30 seconds.

With Visual Studio it’s easier:  Just right-click on the variable and select “Encapsulate Field”.  It will come up with a reasonable property name and automatically generate the code and set the variable to private.

Pretty nice, but nothing to write home about.

But, here’s the magic:

All references to that variable in code are AUTOMATICALLY changed to refer to the property.  If that member variable was used in 50 different places, Visual Studio just saved you the trouble of making 50 different changes or doing a search-and-replace that may or may not get everything on the first try.

Of course, this doesn’t automatically update any XML files that have been saved using the old variable name.  To take care of that you can do one of two things.

1. Do a search and replace in every XML file that your class would have been serialized to and hope you didn’t miss one.
2. Use the XmlElementAttribute on your property to map the saved attributes to your new type:
[XmlElement("_keyword")]
public string Keyword
{

#2 is obviously safer and easier, especially since it doesn’t require changes to existing data.  Of course, your data files might be clearer to read if they used the exact property names, but do you want to go through the trouble?  Likely not.

Yesterday I opened up the source code for the Basternae Client in order to make a few changes, fixes, and updates.  What I had forgotten in the two years since I had been programming C++ actively is what a pain in the behind it is to get anything done in C++.

Sure, you can do anything with it, but there’s so much tedium and overhead involved that it takes forever to get anything done.  Sure, it’s great for low-level code where you’re tossing bits and bytes around, but for user interface development it’s just too unwieldy.

Out of frustration, I sat down and rewrote most of the client in C# in a few hours.  Mind you, it’s not fully implemented, but it’s usable as a telnet client.  I’d say about 8-10 more hours of development time and it’ll be ahead of where the other client was.

That makes this the third version of the client.  The first version was pure SDL with C++.  The second version was SDL combined with wxWidgets.  The third version is C#.NET and WPF.

Another benefit of switching to WPF is that the CPU utilization of the client has gone down tremendously, mainly because we’re using only one interface drawing library now.

In the process or getting an alpha version of the editor ready I’ve found that I had to separate the game code, a.k.a. “business logic” from the data, a.k.a. “object model”.  Otherwise I’d have to include the entire MUD engine in the editor download.  Since that’s not something I want to do I’ve had to pull them apart.  It’s a lot like pulling apart a cold grilled cheese sandwich, and as expected, the bread did tear a little.

The “core rewire” still needs some work, but I should have an “alpha”, a.k.a. “try it and see how broken it is or isn’t” version of the zone editor out sometime this month.

The connection state management code in the socket layer of Basternae has always been what I call “spaghetti code”.  It was a single method containing a huge switch statement with pretty sizable blocks of code for each case.  Tracing program flow for characters that were not actively playing was always difficult due to the complexity and verbosity of this 1600-line function.

Today I refactored it into a bunch of more sensible pieces that go together a lot more smoothly.  The 1600-line function is now 80 lines, I can actually tell what’s going on during program execution, and a handful of confusing and unused variables have been eliminated.  Huzzah!

It wouldn’t have been unrealistic for the designers of .NET to find a way to make this work:

foreach( Item i in ItemList )
{
  if( i.ShouldBeRemoved )
  {
    ItemList.Remove(i);
  }
}

What happens is you get a ‘collection modified’ exception and you’re hosed. You can’t move to the next item in the list because removing the item broke the list. It wouldn’t have been that hard for the design of IEnumerable (the thingy that makes foreach possible) to keep track of where the next item was even after a removal.

Instead of being able to use the above code, something like this clunky bit is required:

for( int i = (ItemList.Count - 1); i >= 0; i– )
{
  if( i.ShouldBeRemoved )
  {
    ItemList.Remove(i);
  }
}

It’s like telling someone they can avoid head-on car collisions by always driving in reverse.

Anyhow, there was a bit of a problem with the Select() command and socket management, and this was the solution. The socket code is now functional and stable enough that I can log in and run around trying to play the game. It’s not terribly playable yet — I have a *LOT* more work to do, but it’s still theoretically possible that a development server could go up i mid-but-more-likely-late May.

I completed the last of the code for the command processing engine today. Not much detail to report — it’s done and seems to work well enough.