When I see a class that is 500 lines or more I start to question the design of that class. That also goes for any methods that are more than just a handful of lines long.
For the last couple of months I've been reading through the source of various roguelikes and I'm shocked at how big some of the files can be -- one was almost 20K lines long. Yikes! We have a saying where I come from; "code is written once, but read many times."
Considering that many roguelikes take years to complete it's quite unlikely you'll remember exactly how all your code works, so you're going to be spending considerable time reading through what you previously wrote. Traversing a ten thousand line file trying to find where you
think that piece of code is is not what I'd call an enjoyable pastime.
The basic rule of good OOP is that each class/method should have a single responsibility. Admittedly, that's a bit trickier in something such as dungeon generation, but any code with tightly related functionality could be split out into its own class. Methods that are dozens/hundreds of lines long should be extracted into smaller methods then where appropriate, extracted into additional classes or modules.
Arguments which state that many files end up creating a bigger a mess are in my eyes incorrect. In the worse case scenario, you're just moving the mess around. However, once we encapsulate related functionality we start to better understand what our code is doing, regardless of how many files that creates. I would agree though that having your 'src' directory containing thousands of files is going to be unwieldy so the answer to this is to create a proper directory structure. An example could be something like;
/src/levels.cpp
/src/levels/doors.cpp
/src/levels/traps.cpp
Over the last few months I've been working through a book about refactoring and this more than anything has helped me better understand how to break code up into more manageable chunks. I highly recommend you take a look at "Refactoring: Improving the Design of Existing Code" by Martin Fowler (
http://martinfowler.com/books/refactoring.html).
Show Posts
