Enclave

During my early levels of computer scienceyness, I happened upon a quest that lead me to take AP Computer Science from Biga. Biga is unconventional. Your grade was a cloud, until you got the answers right, or were properly able to convey your understanding. Yes, you could actually present the wrong answer to the question at hand but demonstrate your understanding of the material and be fine. It was fun. Naturally, some parents were not pleased with this methodology of teaching. Somehow they came to the conclusion that the lack of a grade somehow meant the XP was poor. Little did they know.

I had eighth hour APCS with five other friends. It was a small group, which meant it was very focused. I remember hand waving on the whiteboard every sort using a dozen or so magnets with numbers on them, and creating a sweet Roman numeral fractional calculator. It was my introduction to C++ as a language, which, to date is still my favorite language to program in. I got the opportunity to come back and talk to a class about my experiences as a CS major. It just so happened that Biga was getting rid of the text book I had learned from as they were moving to Java *shakes fist*, so I totally picked that up!1.

I am often reminded, at work, of one of the more memorable sections, okay, the only section of the book I remember. It had a number of programming rules. One is particular has stuck with me to this day, though I often forget which number it is. Lucky for me I have this book to tell me things. Book, tell me what the fifth rule of programming is. Book? Damnit book.

Never be afraid to chuck it all and start over, especially at the design stage. If your organization is a mess, patching it generally will produce a patched-up mess, at best.

Rule number five is a concept that people have a hard time following through with. After all, once you have done all that work, you can’t just really scrap it all, can you? It’s, well, your precious. And you don’t want to just go chuck it into lava. If Minecraft has taught us anything, it’s there’s no coming back from lava. But sadly, the precious is created from evil, and <bleep!?> gotta go. There becomes a point where you are dealing with such a poorly designed program flow, that trying to maintain, improve, or even use it is such a time sink that you are literally throwing time away, into lava. Twice.

Of course, throwing away everything when it becomes difficult to understand is equally a problem as you will end up rewriting everything all the time. Even the stuff you wrote. I know I run into what the hell was I thinking when I wrote that syndrome when I look at old code of mine. I’ve also been to know to catch an occasional not written here syndrome as well. It’ll take a bit of XP to reach that point of understanding when a bad design is really a bad design and not genius in disguise. I recommend reading up on what are good coding design principles. These types of books are never perfect in their guidance, and it is always up to you to decide what best fits your particular problem space. But reading what other people consider good practice is a great way to evaluate their conclusions and see if it is something you agree with. Another idea is to work on your equational reasoning skills. Spend time trying to solve a problem in as many different ways as you can, even ways that are not necessarily efficient. Knowing what an inefficiently solved problem looks like and how it can be efficiently solved is an invaluable skill set.

I leave you with the complete list of the six rules of programming, at least for object oriented design. Are they perfect and all encompassing? Psh, no. But they are nice guidelines to keep in the back of your mind.

Number 1

Divide the problem into subproblems by identifying classes from a narrative description of the problem.

Number 2

The key to success in writing an object-oriented program is a complete and consistent description of all classes involved. Take the time to do this before you write any C++ code.

Number 3

If a member data item is accessed only from member functions, make it private. If a member function doesn’t respond to any messages from outside the object, consider making it private, too.

Number 4

An object should communicate as simply as possible with as few objects as possible. When interfaces are large or complex, consider introducing a manager class.

Number 5

Never be afraid to chuck it all and start over, especially at the design stage. If your organization is a mess, patching it generally will produce a patched-up mess, at best.

Number 6

Keep your functions simple. If a function divides naturally into logically related units, consider dividing the function so that it sends messages for action to separate subsidiary functions. These subsidiary functions usually can be described as private member functions.

---

Citations

Decker, Rick, and Stuart Hirshfield. The Object Concept: An Introduction to Computer Programming Using C++. Boston, MA: PWS Publishing Company, 1995. Print.