Unfortunately, Figure 1 is not correct; we’re working on getting that fixed in the article. In the meantime here’s a corrected version:

The WPF Utilities component should not depend on any unit tests

The unit test components should not depend on any other unit testing component

The domain model should NOT depend on the data access layer. Instead, the data access layer should depend on the domain model. The domain model is the core of everything. Acthieving this is not easy, and I’ll post about how to achieve it.

Yesterday, my pair-programming partner mentioned that he thinks code should be art. A few weeks ago, another programmer said she wanted to write beautiful code. These are awesome goals, and I it made me happy that they even realized these are laudable goals; code, application design, and a running program can (and usually should) be beautiful and elegant.

So, I’m going to start a series of posts all about beautiful coding, elegant designs, and creating wonderful applications.

The advice on the above stack overflow discussion is very good, and I recommend reading it. A related post is Joel’ Spolsky’s excellent “The Perils of Java Schools”.

Certainly there’s nothing better for learning about how a computer works internally than programming 2D or 3D graphics routines in assembler and linking that to your hybrid C/C++ program managing the rest of your game. If you’re using a C++ object oriented approach for the elements of your game (weapons, characters, land tiles, whatever) then you can start to get a sense of good object oriented design.

However, my understanding is that very few game programmers are doing things in assembler these days – DirectX with C/C++ is blazingly fast, and DirectX with .NET is usually fast enough and is much nicer to program in with its automatic memory management and the extensive functionality of the .NET framework.

At the heart of becoming a great programmer is – not surprisingly – a desire to become a great programmer! You have to want to write beautiful code using elegant designs to produce wonderful applications. You have to want to write code that you can be proud of, even years later.

It’s going to take at least 10 years. That’s not 10 years working in a big corporation where 50% of your time is writing TPS Reports, 20% is in meetings, 10% is office gossip, and 10% 😉 is maybe spent fixing somebody else’s mess with the cacophony of 5 simultaneous conversations about TPS Reports rage in the cubicles around you.

To really learn to program you need to work on things you’re passionate about – a small personal project, or better yet a large personal project. There’s nothing better than fixing bugs in your own code 2 years later while cursing the idiot that wrote the code for not using a better design and writing some useful documentation.

My own project was a 75,000 line artificial intelligence natural language application written in C++ (and later migrated to C#) that I started shortly after graduating university. It was really hard and I made a lot of mistakes. I fixed them. I made more mistakes, and cursed myself for repeating some mistakes, and then I fixed them. Over 3 years I worked on this project a lot; I learned a lot.

Similarly, back in high school and university I programmed games. I made a lot of mistakes there too, and I learned a lot. A few years ago somebody said to me, “I wish I had your knowledge of computers”. I replied, “It’s easy, just devote years of your life to programming something you’re passionate about.” He didn’t seem interested, and fair enough, but that’s why I can charge a lot for my consulting time.

Of course I still make mistakes, although it’s a lot less now than I used to, and usually I make new mistakes.

I studied math at university, and the amazing thing about studying math is that you’re usually being taught things first discovered hundreds or even thousand of years ago; Newton published Principia Mathematicaover 300 years ago! Computer science and object oriented programming are really only about 50 years old (and yes, I’m not talking about the difference engine), so it’s only natural that as a discipline we’re all still learning. Which, really, is great because it’s a lot of fun.

I saw some very poor code today, and amazingly it was written by a programmer of 10+ years. The programmer had updated an existing class by adding a new parameter – exactly the same parameter – to each and every method of the class. In fact, the object couldn’t work properly without this information. Here’s my Java pseudo-code version of the updated code:

It eliminates the need to check the parameter’s validity in every method. Instead, the parameter can be checked once by the constructor.

It allows the variable to be frozen to avoid accidental tampering – in this case using Java’s “final”, but this can also be done in C#’s using “readonly”, or in VB.NET using “ReadOnly”.

There is no need to deprecate all of the existing methods

It may be possible to leave previous constructors in place and assume a reasonable default, or even use the C++/C#4/VB.NET feature of default parameter values to reduce rework (although this requires a re-compile).

In this case, the change was even more egregious because the class was actually implementing an interface, and the programmer had updated the interface. Updating the interface required all implementations of the interface to pass in the “x” parameter – but “x” was an implementation detail! So the other implementations didn’t need anything to do with “x” whatsoever! (“x” wasn’t an integer in the real code). Instead, using the constructor approach above, any consumer of the interface remains unchanged, and other implementations that do not rely on “x” also remain unchanged, so the impact to the API and the many, many applications that depend on the API is much less.