roject 1: LDPM (Pocket Monsters) — My Collaboration + Code Review Devlog
For Project 1, I worked with a couple classmates while I built out my LDPM (Legally Distinct Pocket Monsters) program. We mainly compared structures, talked through our approaches, and made sure everyone’s classes worked cleanly together.
Before jumping into coding, I took a minute to look over Morgan’s Hangman program from earlier coursework. Not to copy code just to get inspiration on how to clean up my structure, keep things organized, and upgrade the way I handled methods and class responsibilities. It helped me rethink how I designed the base class and how subclasses should act differently but still fit the same mold.
My process was simple: Understand what the base Monster needed Build that first
Add each monster subclass with its own small twist Test attacks/defense as I went Keep everything clean and readable My classmates had slightly different approaches one coded right away, one mapped things out and talking through our styles made the whole thing smoother. They said my code followed the Google Java Style Guide pretty well, and using IntelliJ’s auto-formatter helped a lot.
It proved something important: Sometimes the best way to improve your own code is to study someone else’s clean solution. You see patterns, habits, and clarity that you might miss when you’re staring at your own project for too long.
Before jumping into coding, I took a minute to look over Morgan’s Hangman program from earlier coursework. Not to copy code just to get inspiration on how to clean up my structure, keep things organized, and upgrade the way I handled methods and class responsibilities. It helped me rethink how I designed the base class and how subclasses should act differently but still fit the same mold.
My process was simple: Understand what the base Monster needed Build that first
Add each monster subclass with its own small twist Test attacks/defense as I went Keep everything clean and readable My classmates had slightly different approaches one coded right away, one mapped things out and talking through our styles made the whole thing smoother. They said my code followed the Google Java Style Guide pretty well, and using IntelliJ’s auto-formatter helped a lot.
It proved something important: Sometimes the best way to improve your own code is to study someone else’s clean solution. You see patterns, habits, and clarity that you might miss when you’re staring at your own project for too long.
Comments
Post a Comment