Unit 5 lesson 10 dialog anyone else notice these nitpicks?

CS Principles
1

Let me know if these are too small a nitpick. I am not sure really.

Unit 5 lesson 10 step 8 we see the variables R, G, and B set to the basic color. We then reuse them to set the difference color. I would consider that changing what a variable means, a bad idea. That is, if we wanted to know the red value of the original color where in the code do we use R and where do we use R - 20? In a small function, it might be obvious, but it is a bad practice. Also, Javascript best practice limits capitalizing the first character of a variable for use with object constructors. That last part is probably too small a nit.

Soon after that Alexis says:

Well, I know that’s actually not a problem. If you try to specify a color as something like rgb(270, 290, 300) the actual color will end up being rgb(255,255,255) anyway. It doesn’t break the system, I tried it back when we were doing turtle programming.

Okay, what we seem to see here is Alexis trying something and finding out how rgb() works for out of range values and is now going to use that. It should say that Alexis checked the documentation for the API and knows how rgb() handles values out of range. The difference is in using an undocumented feature of an API and using a documented feature. The former is a bad idea. In the end, they fix it. So no big deal?

Step 12. Alexis talks about adding a function checkCorrect(). It has the single responsibility of checking how many points are scored and saving the score. And then setBoard() is added to it. Now that single minded appropriately named function has additional functionality. At first, it doesn’t seem too bad.

And then we add switchPlayer(). And we add more implementation details having to do with scoring for two players. CheckCorrect() is getting complex. The final straw comes when we add checkGameOver().

In my humble, okay not so much, opinion there should be an extra function added with a name that describes taking a turn in the game like this:

function playerTakesTurn (guess) {
  checkCorrect(guess);
  checkGameOver();
  setBoard();
  switchPlayer();
}

At some point Alexis, the trouble maker, should point out checkCorrect() no longer does what it says.

2

Hey @jdonwells,
I think these are really good points - I agree that some of these items are not ‘best practices’. My guess is that the script/discussion is meant to give students the idea of the design process, but also to create characters that are like our students. I would consider this the beta version of their design, and hypothesize that if two kids were hashing out ideas together their goal is to get something that works, and then to nitpick on the second round!

As you walk through the script with your students, it could be cool to pause at each of those points and ask them, “What would you do differently from Alexis and Michael” or “how can we do this more efficiently/clearly” and then draw out the conversation with your students about how Alexis and Michael a. are not perfect and b. are completing this task in one way, but it’s not the only way (and may not be the best way).

This definitely gives me food for thought as I approach the lesson with my students as well!

3

In terms of teaching your kids, that last change could be useful. We talk about abstraction a lot, but we don’t really show them examples. My current understanding is that abstraction at this level is all about creating domain specific functions and hiding implementation details. Here is an example of abstraction:

function playerTakesTurn (guess) {
  checkCorrect(guess);
  checkGameOver();
  setBoard();
  switchPlayer();
}

What we are doing is creating a description of what it means for a player to take a turn. We use function calls to create a language in the domain vocabulary. We also hide all implementation details completely.

We don’t get to objects until after the exam, but I intend to introduce my kids to the event object. The details are hidden in checkCorrect():

function checkCorrect (event) {
  if (event.currentTargetId == randomButtonId) {
    updateScoreBy(1);
  } else {
    updateScoreBy(-3);
  }
}

More abstraction. This also allows me to show them how to use named functions in the onEvent call like this onEvent("button1","click",playerTakesTurn);. More abstraction. I have been showing them how to do that for a while because I think it reinforces the idea of abstraction. I did this with Unit 5 lesson 5 puzzle 12 in a previous post Abstraction Demo