• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
  • entries
  • comments
  • views

How Uncle Bob, Fowler & Beck, nCrunch and ReSharper changed my code

Sign in to follow this  
Followers 0


I've been trying to do Test Driven Development (TDD) for quite some time and struggled. I've always been what I would term a "traditional" coder - write something, debug it in some custom rigged harness to make sure things work as expected, then move on to the next piece of the system and repeat ad infinitum. This style of coding has got me through literally 20 years of development and so can't be that bad, right?

The problem with this approach is that defects become harder to find and worse, if you change things you have no real idea how they affect other parts of the system. A few years ago, I started adding Unit tests to my code. I'd write my code and then add unit tests around it to break it. This would be good, as I'd end up with more confidence in my code and how it worked. I could change things and know quickly if I broke something. However, this style of coding ended up with untestable or "hard to test" code. I'd end up with methods which required complex setup scenarios to test - and then if I changed the inner workings of the code, all of the old tests would start failing due to the setup being wrong or out of date. Worse, if you needed to change a method signature or modify an interface, it would mean hundreds of tests to change. I'm ashamed to admit it, but at times like this it became easier to discard the tests or restart the class or project.

I felt like I was stuck in a loop. I wanted to "do good" and have tested code, but also I found it hard to achieve. Something needed to change.

I picked up a copy of "Clean Code" by "Uncle" Bob Martin. Anyone who's into "the agile scene" will know of him, he's some sort of evangelist god of good code. I read Clean Code from cover to cover and took a lot of it in. This book evangelizes testable code like no other. It also evangelizes "clean" code. Clean code is simply "code that you understand without documentation". Much of the book talks about removing coding "smells" and references Martin Fowler & Kent Beck's "Refactoring" in the process. I came away from Clean Code realising that I write dirty code. Really dirty code, and *this* is why I can't test it. I also realised that the reason I can't test it is because it was written without being able to be tested; and this is because it's dirty. And when I can't test it, I don't know if it works or not. In fact, I've written stuff that I don't know if it can be run or not.

I've spent most of my life writing code. Some of it is admittedly hacky but stuff I thought was "production" quality is hacky. To find out more, I went into Fowler & Beck's "Refactoring". This book is simply a mine of useful information. The single biggest takeaway from the book is that you must leave any code (including your own) in a better, more understandable and testable state than you left it. This can be as simple as giving variables "good names" (not "i", but something that makes sense to the context) and removing duplication by reducing complex functions into smaller, more composable and understandable parts. It also reinforces SOLID concepts and makes you realise that a lot of the code you write isn't actually great OO code - even though you think it is.

So after spending a lot of the December holiday break with the stark realisation that I write dirty, untestable code whilst thinking I was doing "ok" and knowing that there is a better way, I decided to start doing it.

Two tools jumped out at me. ReSharper and nCrunch. First - nCrunch gives you instant visibility on whether your code is tested or not. Each and every line of executable code has a dot next to it... Red, Green and Black. The dots update in near realtime, to let you know if your code is working or not. Red means your code is covered by a failing test, green means it's covered by a passing test and black is almost the worst kind - it means that it's not covered by a test at all. in short, nCrunch takes out the barrier to attempting TDD and actually makes you embrace it. Having used it daily for a month, I now ensure that the "black" is minimal - in fact it's easier to write a test and make it pass than to face figuring out how to cover the black. You actively try and avoid a black... because not knowing is worse than knowing you screwed up. Black means you might have superfluous code - stuff you wrote without needing.

One big thing in Fowler & Beck's "Refactoring" book is that you try and migrate your code to a cleaner state through refactoring. Refactoring is the act of keeping existing code usable, whilst changing it to a new, cleaner state. A key factor in this is having the confidence to change it, which means having test coverage to prove you haven't broken it. My prior approach to refactoring would be more of the scorched earth process. I'd rip out old classes and methods, having code which didn't compile for hours, or even days... and then after it all, finding out my tests were broken and needed fixing. At this point, I'd often ditch the tests... which I know now is a cardinal sin. Fowler and Beck advocate an approach which means slowly migrating to your new state, whilst ensuring all tests pass with each change. nCrunch provides a mechanism to allow this - you know straight away when things don't compile and things don't work. So you fix them, and move on.

Resharper provides a bunch of useful tools to help you refactor; be it renaming stuff, moving namespaces, changing scope, etc - just generally helping you clean code up line by line. Combined with nCrunch, I can make changes to code and have it verified within seconds - in fact, before I even think I've done, I know I have... because everything is green.

With both of these tools, I've had code which has compiled for 99% for my working day. And I've had test coverage of over 90% for the most part. I realised the other day, that I'd done a large part of coding without having to manually compile once and hadn't hit the debugger in days. Yet I knew my code worked, because my tests were all green.... and there were literally hundreds of them. I recently added a new feature to my code using tests and refactoring; adding this feature resulted in the removal of the old behaviour. Using the techniques I'd learned and the new tools, I was able to add the new feature and migrate my codebase from the old one over the course of few hours. When it came to the point of removing a fundamental class in the old system, I hit delete and hat literally one failing test out of hundreds. And this test was to do with the old behaviour and not relevant to the new system. At this point, I knew I'd hit a pivotal moment in my life.

I'm now in a position that I never thought I'd be. I'm embracing TDD and adding or making large changes to my codebase without fear; I know with confidence that my code works and it's actually more understandable than it used to be. As a result, I feel like I'm becoming a better programmer. Not because I'm smart, but because I know what I write works. And this is a great position to be in.

Sign in to follow this  
Followers 0

1 Comment

Traditional coding method is good enough for me, working with 30,000 line code projects.


Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now