Vish's Journey in Computer Science

I am thoroughly enjoying the classes on writing clean code under the aegis of Professor Al-Faris in Software Process Management course. While looking for more material outside class, I found a blog post titled “How to Write Clean Java Code: Best Practices” on Digma’s website https://digma.ai/clean-code-java/. Since we work a lot with Java especially in our design patterns (Software Construction Design and Architecture under Professor Wurst) and project classes—I felt this blog would be perfect to learn some practical ideas on writing cleaner code. It directly connects to the course concepts of good processes, readability, and long-term maintainability.

Summary of the Blog Post

The blog highlights several clean-code principles specifically focusing on Java. It talks about using meaningful names, keeping methods small, breaking down complex logic, and making classes more focused on single responsibilities. It also covers organizing projects so that packages and modules make sense. Other topics include avoiding unnecessary comments, choosing good formatting, and using tools like linters and static analysis to keep code quality consistent across a team. The blog also mentions the importance of avoiding side effects and making code more predictable so that debugging becomes easier.

Why I Picked This Resource

I picked this blog mainly because I sometimes struggle with writing code that is easy for other people to read. In group projects, especially in CS-343 and other classes, I’ve noticed that even when my code works, people ask me to rewrite parts to make it more understandable. Since the course emphasizes professional development and communication skills, I wanted to learn more about how to write code that doesn’t confuse future developers—including a future version of myself. Also, I’m working with Java in my Android and backend mini projects, so the resource felt immediately relevant.

What I Learned and My Reflections

One thing that really affected me was the section on method size and single responsibility. I realized I often cram too much logic into one method because it feels “efficient” while writing it. But the blog explains that smaller, focused methods improve readability and make testing easier. Another important point was naming. I always knew naming mattered, but the blog explained it in a more practical way—names should communicate intent, not just function.

I also learned about using automated tools to maintain code quality. Honestly, I never used static analyzers or formatters seriously, but now I see how they support good software processes, which we discuss a lot in this class. Clean code isn’t just a personal style; it’s part of a team’s workflow and long-term sustainability.

How I Will Apply This Going Forward

Going forward, I plan to be more disciplined about breaking up my functions, using stronger naming, and removing unnecessary comments. I also want to integrate automated formatting and code-quality tools in my personal projects, so I get used to writing cleaner code consistently.