I spent this week on the Markov assignment and teamed up with my fellow student Taylor, also receiving 19.5 out of 20 for the project. Both of us treated the assignment consecensively and not only considered making the code work but also how to make the code more beautiful and user-friendly. Teamwork helped us to swap ideas, contrast the solutions, and make our end implementations better.
My personal strategy for solving the Markov assignment started with understanding the problem clearly. I didn’t jump into coding right away. Instead, I mentally mapped out how I would represent word transitions using a HashMap>. I began by writing the structure of the class and setting up constants and member variables like BEGINS_SENTENCE, PUNCTUATION_MARKS, and prevWord. I then built methods in stages—starting with addWord, addLine, and addFromFile—and tested each one before moving on to the next. I wanted the code to be readable, so I included meaningful comments throughout. Taylor provided helpful feedback and worked with me to refine parts of the logic and sentence generation so it would appear more natural and be easier to read and maintain.
Taylor’s approach was a bit different from mine. They started to code early and used simple test files to test functionality throughout. They sought to have immediate feedback through running and testing small bits of code. Once their logic was satisfactory, they returned to make the structure neat and readable. This made me realize that early test case development is an effective way to discover problems earlier. I also appreciated Taylor’s method of shortening conditionals and neatening sentence structures.
If I could do the whole thing again, I would draw more inspiration from Taylor’s test-first strategy. Defining small test cases before writing would probably have been a good time-saver when debugging. I would also rough out my method responsibilities more explicitly before coding, in terms of defining a better structure earlier on. Overall, my code is good, but I realize that I could make my whole development process even better. Taylor also commented on how my code conformed to the Google Java Style Guide. They stated that my variable names and comments were clear, that the structure wasgood, but that they observed some lines of code being longer than 100 characters, and that they could use consistency in spaces between methods. I appreciated these remarks and made use of them in refining the ultimate version of the assignment.
Before this week, I didn’t even realize that you could automate the enforcing of a style guide, but now I’ve been introduced to programs like Google Java Format and Checkstyle. In the future, I’ll apply one of these programs in a project so that it will be less work for me to generate clean, consistent code.
Overall, my collaboration with Taylor made my code and my programming abilities better. In addition, I gained more insight into how cooperation will open you up to improved coding practices and software that you would not have encountered otherwise.