Skip to content

Conversation

@JansenMartin
Copy link

@JansenMartin JansenMartin commented Feb 23, 2019

Adagrams

Congratulations! You're submitting your assignment.

Comprehension Questions

Feature Feedback
What are the components that make up a method? A method has a name and sometimes parameters. This first line is known as the "signature". Inside the method is a set of expressions that returns a value.
What are the advantages of using git when collaboratively working on one code base? The partners can share code more efficiently and with less room for error/confusion.
What kind of relationship did you and your pair have with the unit tests? The unit tests helped identify problems in our logic that we wouldn't have seen otherwise. They gave us a clearer direction of what code needed to be revised in order to meet minimum requirements.
Does your code use any methods from the Enumerable mixin? If so, where and why was it helpful? In the draw_letters method, we used the .map Enumerable. It was helpful because we were able to create an array by looping through a hash -- without needing to initialize the array and/or worry about scope.
What was one method you and your pair used to debug code? We went through a debugging process with Charles. We went through the stack backtrace to find bugs in our methods and also used pry to dig around in our variables. When we needed to dig deeper, we also used puts statements.
What are two discussion points that you and your pair discussed when giving/receiving feedback from each other that you would be willing to share? We both enjoyed the camaraderie and joint-ownership of working through the code together. Jansen appreciated Kate's keen eye in catching errors while she coded. Kate appreciated Jansen's patience, encouragement, understanding, and enthusiasm!

@droberts-sea
Copy link

Adagrams

What We're Looking For

Feature Feedback
General
Answered comprehension questions yes
Small commits with meaningful commit messages I would like to see more descriptive commit messages. Your commits should tell the reader a story about what changed when and why, without them having to dig through the code or project requirements.
Code Requirements
draw_letters method
Uses appropriate data structure to store the letter distribution yes
All tests for draw_letters pass yes
uses_available_letters? method
All tests for uses_available_letters? pass yes
score_word method
Uses appropriate data structure to store the letter scores yes
All tests for score_word pass yes
highest_score_from method
Appropriately handles edge cases for tie-breaking logic see inline
All tests for highest_score_from pass yes
Overall

Good job overall! This code is clear and well-organized. I've left some inline comments below about things that could be cleaned up, but in general I'm pretty happy with what I see here. Keep up the hard work!

# WAVE 1
LETTER_POOL = {a: 9, b: 2, c: 2, d: 4, e: 12, f: 2, g: 3, h: 2, i: 9, j: 1, k: 1, l: 4, m: 2,
n: 6, o: 8, p: 2, q: 1, r: 6, s: 4, t: 6, u: 4, v: 2, w: 2, x: 1, y: 2, z: 1}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of a constant here. This data structure makes it very easy to tell how many there are of each letter.

letter_draw = LETTER_POOL.map do |key, value|
(key.to_s * value).split("")
end
letter_draw.flatten!

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you use more descriptive variable names here than key and value?

hand_count = letters_in_hand.count(letter)
if user_count > hand_count
uses_available_letters = false
break

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than keeping this extra variable uses_available_letters here, you could return false here, and return true at the bottom.

SCORE_CHART = {1 => ["a", "e", "i", "o", "u", "l", "n", "r", "s", "t"],
2 => ["d", "g"],
3 => ["b", "c", "m", "p"],
4 => ["f", "h", "v", "w", "y"],

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea of using a hash for this, but I think I would switch the keys and the values. I would go with something like:

LETTER_SCORES = {
  "A" => 1
  "B" => 3,
  "C" => 3,
  "D" => 2,
  # ...
}

Then to get the score for a letter, you can say LETTER_SCORES[letter].

def tie_breaker(word, current_best, list)
new_best = current_best
if word.length == current_best.length
if list.index("#{word}") < list.index("#{current_best}")

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I love that you broke this complex logic out into a separate method. Good organization!

if word.length == 10
best_word = word
best_score = score
break

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will do the wrong thing if there's a short word that scores higher than a 10-letter word. For example:

  pry -r ./lib/adagrams.rb
[1] pry(main)> word_a = 'ZZZZZZZZZ'
=> "ZZZZZZZZZ"
[2] pry(main)> word_b = 'AAAAAAAAAA'
=> "AAAAAAAAAA"
[3] pry(main)> score_word(word_a)
=> 98
[4] pry(main)> score_word(word_b)
=> 18
[5] pry(main)> highest_score_from([word_a, word_b])
=> {:word=>"AAAAAAAAAA", :score=>18}

Paying attention to word length 10 only matters for breaking ties.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants