Exercise 36: Day 1: Designing and Debugging: Learn Ruby the Hard Way: Practicum

I've been at this little project now for the better part of six weeks, and I feel I've covered a lot of ground in that time. With just a couple of exceptions, I've been able to commit to doing a section every day (give or take a few; I took off for Thanksgiving weekend and my birthday). However, I'm going to change that up a bit, in that this is going to be a litle project that requres a bit more time.

I'm going to present the homework section first, and give myself a commitment of actually digging in and doing something with it in the actual time recommended. That means we'll be seeing update posts for Exercise 36 for the next week. Huh?! Yep, it may not win any prizes or be all that good, but I'm going to work on a week long project right here, in public, and see what I come up with. It may be OK, it may stink to high heaven. Either way, y'all will be able to critique it and have fun with it either way.

Homework


Write a similar game to the one that I created in the last exercise (Exercise 35). It can be any kind of game you want in the same flavor. Spend a week on it making it as interesting as possible. For extra credit, use arrays, functions, and modules (remember those from Ex. 13?) as much as possible, and find as many new pieces of Ruby as you can to make the game work.


There is one catch though, write up your idea for the game first. Before you start coding you must write up a map for your game. Create the rooms, monsters, and traps that the player must go through on paper before you code.

Once you have your map, try to code it up. If you find problems with the map then adjust it and make the code match.

So there's the challenge, and here's the first part of it.

My kids are fans of Ghost Adventures, so we'll take a journey through a haunted house.

Approaches to house: main road, back road

Main Road: goes through section where road is washed out, must travel by foot, come across poisonous snakes and wolves. Dodge snakes or get bitten, dodge wolves or get eaten.

Back Road: ends at swamp, find raft to cross, watch for alligators, avoid or get eaten.

Arrive at house: go through Front Door, Side Door

Front Door: floor boards give way and person falls into basement, look for ways to get out

Side Door: person is allowed access, but debris blocks the way. User must move debris to get through.

And the rest I'll flesh out and post tomorrow along with a flow map of sorts.

Anyway, this section covers tips and tricks to start using when designing and debugging programs and some "in context recomendations" (sorry, after so many years of fighting the use of a term, I cannot bring myself to say the words "best practices" with a straight face, so no reason to start now ;) ). Note, these are pretty much verbatim from the book with a couple of slight modification so it doesn't feel like I'm just copying the section directly (though I mostly am):


Rules For If-Statements

- Every if-statement must have an else.


- If this else should never be run because it doesn't make sense, then you must use a die function in the else that prints out an error message and dies, just like we did in the last exercise. This will find many errors.


- Never nest if-statements more than 2 deep and always try to do them 1 deep. This means if you put an if in an if then you should be looking to move that second if into another function.


- Treat if-statements like paragraphs, where each if,``elsif``,``else`` grouping is like a set of sentences. Put blank lines before and after.


- Your boolean tests should be simple. If they are complex, move their calculations to variables earlier in your function and use a good name for the variable. Easy to understand variables can help make your code "self commenting".


Warning

Never be a slave to these rules in real life. If you think a rule is stupid, try not using it. You will likely be just fine. Rules tend to help us stay focused and mindful of good process, but sometimes, a break with convention is warranted. The old music theory joke comes into play here... you have to know the rules first before you can effectively break them.

Rules For Loops

- Use a while-loop only to loop forever, and that means probably never. This only applies to Ruby, other languages are different. What this means is if you want to make a condition that always returns to the same point to keep doing the same thing, that's where a while loop makes the most sense.

- Use a for-loop for all other kinds of looping, especially if there is a fixed or limited number of things to loop over.

Tips For Debugging

- Do not use a "debugger". A debugger is like doing a full-body scan on a sick person. You do not get any specific useful information, and you find a whole lot of information that doesn't help and is just confusing.

- The best way to debug a program is to use puts or print to print out the values of variables at points in the program to see where they go wrong.

- Make sure parts of your programs work as you work on them. Do not write massive files of code before you try to run them. Code a little, run a little, fix a little.


TESTHEAD's TAKEAWAYS:

Every one of these suggestions individually makes sense. taken together, they look like they would go a long way to helping make for elegant and functional code that would be generally easy to maintain. Well see how well I do over the coming week, I guess :).