WK 03 learning journal , hangman team review.

 

1. Code Reviewed

• Isaiah’s HW01 submission
  
  

• Janaye’s HW01 submission
  
  

2. Reviews I Provided

Isaiah

• Variable names: loader, game, random, numberOfHints clearly describe their roles. Consider renaming loop variable c to guessChar.
  
  

• Logic efficiency: Game flow works smoothly. You rebuild the display string and used‑letters list on every guess—fine for small words, but caching the display and using a Set<Character> would speed up lookups.
  
  

• Imports & warnings: No unused imports or compiler warnings. Note that FileNotFoundException is imported but never explicitly referenced (caught by your generic Exception).
  
  

• Formatting: Indentation and braces are consistent. A couple of lengthy Javadoc lines could be wrapped for readability.
  
  

• Comments: Javadoc is present on every public method—just remove the extra <br> tags.
  
  

• Unit tests: All tests ran unchanged and passed—nice job!
  
  

Janaye

• Variable names: PLACEHOLDER, secretWord, guessedWord, remainingGuesses, usedLetters are crystal‑clear.
  
  

• Logic efficiency: Elegant use of StringBuilder to update the placeholder word; the core loop flows smoothly.
  
  

• Imports & warnings: No stray imports or warnings—everything you imported is used.
  
  

• Formatting: Indentation and brace style are perfectly consistent; your <ul> lists in Javadoc enhance readability.
  
  

• Comments: Fantastic Javadoc coverage—your docs practically teach the code.
  
  

• Unit tests: All tests ran untouched and passed—great job satisfying every requirement!
  
  

3. Feedback I Received

Isaiah

“Hey Xavier—just wrapped up your HW01, and here’s my take from my eyes as Isaiah:

• Your variable names are rock‑solid. Seeing names like secretWord, remainingGuesses, and usedLetters instantly maps to what they do—made getting into your flow effortless.
  
  

• The core game loop is clear and works as expected, but I spotted a couple of lingering TODO comments in your code. You’ve nailed the requirements, so you can drop those now and avoid any confusion down the road.
  
  

• You only pull in imports you actually use—nice and lean. I ran your code with zero compiler warnings, which is always satisfying.
  
  

• Formatting feels consistent: braces, indentation, and spacing are all on point. A couple of your lines ran long (especially in the Javadoc), so wrapping those would help the eye track better.
  
  

• Your Javadoc is solid on most methods, but a handful of public methods are missing it—adding those will round out the docs nicely.
  
  

• All of your unit tests ran unchanged and passed—great job hitting every scenario the first time.
  Overall, this is a clean, well‑structured submission. Tidy up those TODOs, fill in the missing Javadoc, and wrap the long lines, and you’ll have a polished final version.”
  
  

Savannah

“Variable names: Clearly labeled
Logic efficiency: Core logic was functional
Unused imports or warnings: No warnings found
Formatting: Some lines were extra long, TODO comments were left in after their tasks were completed
Comments: Javadoc present for most methods
Unit tests: Tests are unmodified and are all passing
Well done!”

Janaye

No feedback received.

4. Trends Identified

• Descriptive variables: Everyone praised clear, intent‑matching names.
  
  

• Stable tests: Unit tests remain unmodified and pass consistently, ensuring reliability.
  
  

• Documentation focus: Thorough Javadoc on public methods was highly valued.
  
  

• Formatting consistency: Indentation and brace style were uniform, though line‑wrapping varied.
  
  

• Cleanup opportunities: Multiple submissions contained TODO comments or extra Javadoc tags that could be removed.
  
  

5. Reflective Questions

What improvements would you make to your code/what was suggested?

• Remove leftover TODO comments.
  
  

• Wrap overly long Javadoc lines.
  
  

• Add Javadoc to the few public methods I missed.
  
  

• Rename loop variable c to guessChar and consider caching the display string.
  
  

Which unit tests were the hardest to pass?

• Simulating user input with the random word generator was the trickiest—had to ensure reproducible guesses.
  
  

How do the existing tests function and could they be improved?

• They drive a full game session and verify final outcomes. To improve coverage, I’d add edge‑case tests for invalid input, empty word lists, and repeated guesses.
  
  

Do the existing unit tests cover the full range of the subclasses?

• Not fully—there’s no integration test between classes or specific tests for hint functionality.
  
  

How would you change the unit tests?

• Add tests for non‑alphabetic input, verify getGuessedWordString() before any guesses, and confirm that getNumberOfHints() decrements correctly when hints are used.
  
  

What did you struggle with?

• Learning Java syntax nuances and handling file I/O for the first time felt overwhelming.
  
  

What did one of your teammates struggle with?

• Isaiah mentioned difficulty validating menu input without triggering exceptions.
  
  

Was any part of the code a struggle for YOU?

• Translating requirements into Java logic and mastering the StringBuilder update workflow.
  
  

Was any part of writing the code easy for YOU?

• Coming up with goal to accomplish the assignment. Easy thanks to the TODOS
  
  

What was your biggest HW1 victory?

• Refactoring my input handling so that all tests passed reliably on the second try.