Systematic Program Design - Part 1, Sec. 1a & 1b

I spent 5 hours at the library today, working though some WGU course work, and week 1 of this course. I'll probably start on week 2 after I finish this blog post, but I wanted to write this while everything was fresh in my mind. If you were to go by the syllabus you are expected to spend 9-15 hours working on sections 1a and 1b, but I finished both sections in 3 hours.

To be fair, most of the information I went over is stuff I already understand, so I was able to go at a very quick pace. I also skipped 3 modules to keep up my pace. I watched 12/14 lectures at 2x speed and I coded all of the problems in C#, rather than downloading DrRacket and coding in BSL.

If you're not familiar with a programming language already, I would suggest using the tools provided. I found BSL to be an ugly language, but the IDE, DrRacket, appears to be very beginner friendly. There's a section about drawing shapes with BSL, that DrRacket makes very easy, but I skipped doing any actual drawing because I've already done a lot of drawing in C#, and I was still able to answer the quiz questions by understanding the BSL functions that draw shapes.

If you took CS-50 before moving on to this course, you probably won't learn a whole lot of new information in section 1a, but you'll have to go through it, or at least review the material, in order to be able to use BSL. Section 1b, however, is all about writing functions and tests for them. This section is a gem, and you'll want to work though it and understand everything thoroughly. I can't tell you how many job opportunities I've looked at that included the requirement: 'experience with unit testing and test driven development'. I see that line everywhere, it's probably in about 80% of the job requirements I've reviewed.

The rest of this blog post is more of an exercise for myself to regurgitate what I learned, and you may want to stop reading here, but feel free to continue on, or stay tuned for the next post about my thoughts on week 2's content.

I said I wasn't using BSL and the DrRacket IDE right? Well shoot, I can't use the check-expect function if I don't write in BSL, so I can't do the whole section on testing... or can't I?

I couldn't let a lack of BSL support stop me from learning the material and actually coding the problems. I've seen a video or two on unit testing in C# but I've never done it myself, so I had to take this opportunity to learn how to create unit tests. I couldn't just write the code on paper, and pretend like I did the exercises. What did I do then? Well, I went to Microsoft's documentation and figured out how to write unit tests. As it turns out, that was quite easy for me to grasp, though I must stress again, if you're not familiar with another programming language, stick to BSL. I won't explain too much about unit testing here, you can certainly read the documentation above and gather some insight whether you know C# or not. In particular I suggest understanding the AAA approach to unit testing.

The AAA (Arrange, Act, Assert) pattern is a common way of writing unit tests for a method under test.

• The Arrange section of a unit test method initializes objects and sets the value of the data that is passed to the method under test.
• The Act section invokes the method under test with the arranged parameters.
• The Assert section verifies that the action of the method under test behaves as expected.

The value in going through section 1b is that you'll learn the HtDF (How to Design a Function) recipe, if you're familiar with writing code and designing functions, it's going to seem a bit cumbersome at first, and if you're not familiar with designing functions it's going to seem quite complicated. The essence of the HtDF recipe is this:

1. Signature, purpose and stub.
• The purpose is generally a problem statement. Or a description of what you're trying to solve. One simplified example is to design a function to pluralize a word.
• Ex. Input: "Dog" Output: "Dogs"
• The signature of a function describes the type of input and output
• String -> String
• The stub is a syntactically complete function definition that produces a value of the right type. It doesn't tell you how the function will complete it's work, only that there will be a function defined in such a way, and it will produce this type of output.
• (define (string str) "")
2. Define examples, wrap each in check-expect.
• An example is simply a snapshot of what a call to your function would look like. You're asked to wrap it in a check-expect function call, because this is the function that's going to test that your example is in the proper form.
3. Template and inventory.
• The template is what your function will look like with everything except the actual work to produce the desired output. Simply write the work as an ellipse '...'
• (define (string str)
      (... str))
4. Code the function body.
• I mentioned it was cumbersome right? At this point we can finally write the code that does the work for us and produces our desired output.
• (define (string str)
      (string-append str "s"))
5. Test and debug until correct
• Hopefully, at this point, things are pretty strait forward. If your test(s) fail, check first that you wrote your test(s) correctly. If you did, then check that you wrote your function correctly and that the body is doing the correct work.

Keep in mind, you don't have to get everything right the first go-around. You may find that you write a function for a Number that produces a Number. For instance, you might write a function that turns any number into the positive version of that number. You may write your signature as such: Number -> Number, but then realize that your output is always part of the natural numbers, in which case you should go back and change your function's signature to be more specific. Number -> Natural Number, for instance. Really, you should probably go as far as to say Integer -> Natural Number if indeed your input is an integer.