Software by Steven

Sometimes a square peg is a round hole

A retrospect: 3 years of coding changes

I’m readying for graduation, and I’ve taken a looks back at how my coding style and structure has evolved (and am I ever glad it has). At first, there was a mess of convoluted logic, not-so-poly morphism, and generally bad code. The best example for this has been an ongoing project of mine for the last 3-4 years. I’ve been working on a chess engine, which has undergone massive rewrites as I’ve learned more. Without any knowledge of design patterns and limited knowledge of exactly what a compiler does, it was an unreadable mess of code. The only thing saving it from being spaghetti was structure.

private bool canPiecesMove()
{
  char colToMove = whiteTurn ? 'w' : 'b';
  short[][] moves;
  short[] discoveryCheckOrig = discoverCheckPiece;

    for (short x = 0; x < 8; x++)
    {
      for (short y = 0; y < 8; y++)
      {
        if (board[y, x] != null && board[y, x].Colour == colToMove && board[y, x].Value != (ushort)Game.PieceValues.king) // Come to own non-king piece
        {
          moves = board[y,x].getMoveableSquares(x,y);
          if (board[y, x].Value == (ushort)Game.PieceValues.pawn)
          {
            if (board[moves[0][1], moves[0][0]] == null && !isPinned(x, y, moves[0][0], moves[0][1])) // Pawn can move forward                             {                                 discoverCheckPiece = discoveryCheckOrig;                                 return true;                             }                             if (moves[1][1] >= 0 && moves[1][1] < 8 && moves[1][0] >= 0 && moves[1][0] < 8)
            {
              if (board[moves[1][1], moves[1][0]] != null && board[moves[1][1], moves[1][0]].Colour != colToMove && !isPinned(x, y, moves[1][0], moves[1][1]))
              {
                 .....
              }
            }
          }
        }
      }
    }
  }
}

While it worked, it was a mess. 3 rewrites later it now takes advantage of 3 further years of knowledge and education. I’m currently working on move generation in preparation for eventual AI, but not much real feature progress has been made on the engine since. Refactoring has been the main draw of effort.

Have I been bikeshedding in my development? Many friends say yes, but I disagree. Sure, additional features are few and far between, but isn’t one of the rules to develop one to throw away? Doesn’t the release early, release often mantra allow for ingenuity and inspiration to be unhindered by what “must be perfect?” I’ve learned a great deal since my first pass at this chess engine, and about the only unchanged code is UI-based. Without the willingness to go back and fix what wasn’t broken, I feel something would’ve been lost.

So I say this: Never be afraid to reinvent your own wheel.

One Response to A retrospect: 3 years of coding changes

  1. Pingback: How I learned to stop worrying and love clean code « Software by Steven

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.