Emilce & Maria - Octos - C9

[emilcecarlisa]

Word Guess

Congratulations! You're submitting your assignment.

Comprehension Questions

Feature	Feedback
How do you feel you and your partner did in sharing responsibilities? Challenging to agree to work on the same task.
For each partner what parts of the project did you find challenging? Emilce-found it challenging to write logical code. Maria-It was a challenge to be on the same page about what to do next.
Describe an instance where you used a method for something to encapsulate the functionality within your class. What does it do? What are its inputs and outputs? We had a method to select a random word where the input was raw data and output was the result of the sample method.
Describe an instance where you used a local variable instead of an instance variable. Why did you make that choice? Random_word_length is a local variable because the value changes depending on the word.
What code, if any, did you feel like you were duplicating more than necessary? We could have used more instance variables.
Is there a specific piece of code you'd like feedback on? We would like to sit down and meet with you about improving the code we have in order to complete the assignment. Please let us know your availability after you provide your comments.

[droberts-sea]

Word-Guess Game

What We're Looking For

Feature	Feedback
Baseline
Regular Commits with meaningful commit messages.	some - your commit messages look good, but I would like to see more frequent, granular commits
Readable code with consistent indentation.	yes - some of your variable names are a little misleading, but otherwise readability is good
Answered comprehension questions	no - looks like these were missed
Product Functionalities
Created a Class to encapsulate game functionality.	yes
Used methods to DRY up your code.	some - see inline
Created instance variables & local variables where appropriate.	yes
Used Arrays to store lists of letters guessed.	yes
Used variables & random numbers to allow the game to function with multiple words, no hard-coded answers.	yes
Programmed "defensively" to detect errors in user input.	no - I was able to enter "foo", "" and "#$^%" all as "valid" guesses

This is a good start, but it feels like there's quite a lot of work still to be done here. The core functionality of the game (guess letters in a loop) is there, but there's no artwork, no way to loose, and much of the user interaction still feels very unpolished.

I've left a number of inline comments below, which you should spend time reviewing. Feel free to reach out with questions about them, or if you want to talk through the project.

One impression that I get is that you had trouble getting started, and ended up running out of time. This is a common pattern with novice programmers: when confronted with an empty file, they freeze up and don't know where to start. One way to practice this is through the Benjamin Franklin method, where you take an existing resource (say a ruby file I wrote in lecture, like song.rb, and attempt to replicate it in the same order I did without looking at the original. Then go back and review the lecture or notes, and see how you did. Identify the places where we diverged, and then come back the next day and repeat, either with the same resource or with a new one. This will start to build up those mental patterns, both of how the pieces fit together in the finished product, and of how to build something new from scratch.

[droberts-sea]

Here you have an instance variable @art, but I don't see that it's ever used. You're also setting a value for it, but your constructor does not take a art parameter.

[droberts-sea]

You should have an explicit return here:

return random_word

[droberts-sea]

I like that you split initialization out into small, manageable methods.

[droberts-sea]

The attr_readers you've made on line 33 are both for methods. attr_readers give access to instance variables, for methods they don't make any sense.

[droberts-sea]

I'm not sure this if statement makes sense here. At this point letter_of_random_word should point to the last letter in the word that's being guessed, so checking whether that is what the user guessed isn't very meaningful.

If you do need to track incorrect guesses separately, you would need a separate boolean variable, maybe called correct_guess, that is set to false before you loop through the letters in the word, and updated to true if the letter ever matches.

[droberts-sea]

You decrease the number of guesses available even if the guess was correct.

[droberts-sea]

This loop would be a good thing to pull into its own instance method. The signature might look like:

def check_guess(letter)

[droberts-sea]

There's no way to loose this game!

[droberts-sea]

Calling this method guess_letter is a little misleading - this method plays the entire game, top to bottom. Realizing when your method is getting away from you and becoming bigger than you intended is an important skill to practice.

One way to combat this tendency is to plan out how your code will be called before you start writing the class. You might start by building a driver loop down below:

game = Word.new
while !game.is_over?
  game.print_state
  puts "Letter please"
  letter = gets.chomp
  game.guess_letter(letter)
end

This can serve as a sort of road map, limiting how big your methods need to be and keeping you on the right track.

[droberts-sea]

This is another place where the name of the class, Word, indicates it will be responsible for some small piece of functionality, but instead you've ended up throwing the whole game in here. You should either rename the class to something like Game, or move functionality out.

Knowing what your classes and methods are not responsible for is just as important as knowing what they are supposed to do.