Category Archives: CS-348

The Clean Code Debate: General Practices vs. Uncle Bob

For this quarter’s blog post, I decided to speak more about the principles of clean code. The resources I discovered when exploring this topic surprised me. I have understood the general concept of writing code that is easy to read, maintain, and understand from the start of my time here at Worcester State University. However, now I have been introduced to the more specific and controversial perspective explained by Robert C. Martin (aka, Uncle Bob). My goal with the resources I chose was to compare Uncle Bob’s approach against how clean code is viewed in more general practices.  

This resource, Clean Code: The Good, the Bad and the Ugly, explores Uncle Bob’s perspective on clean code, while the author identifies components they see to be good, bad, and ugly. The resource “Clean” Code, Horrible Performance, tests Uncle Bob’s clean code components and explains how it impacts performance. Lastly, there are two other resources that give examples of general practices of clean code.

From what I understand, the core idea of clean code is that people read code way more often than they write it, so it is important to prioritize clarity. However, on the other hand, Uncle Bob’s perspective advises for small functions and almost no comments. Some of Uncle Bob’s advice is similar to general clean code practices, but this specific advice leads to some conflicts.

The first two resources showed that sticking too closely to Uncle Bob’s principles can actually lead to decreased performance. This happens due to highly fragmented code (following his principles on small, single-purpose functions), which can be less efficient for the machine to run. The main takeaway from these conflicting views is that Uncle Bob’s ideas are helpful guidelines, but they are not universal rules. It is important to understand the trade-off between absolute readability and optimal performance based on the focus and needs of the project you are working on. 

The advice against using comments genuinely surprised me. In one way, comments are a great way for beginner coders to track the purpose of their code, and to boost their understanding of certain components (i.e., loops, methods, functions, classes, etc.). At least, that is what I often used comments for when practicing coding alone. Now I understand that, when working on a team, those initial comments can quickly become confusing and unhelpful. If a comment is not deleted or updated when the code changes, it becomes misleading. Your code should describe itself using good variables, functions, and method names. If you need a comment to explain what each part of the code does, that may be a sign of poor coding design. 

I had intended to use clean code as I continue practicing coding. However, now I have more tools under my belt to make sure my code is not just digestible for me, but also digestible to someone who may need to read or update my code without me there to explain it.

Main Resources:
“Clean” Code, Horrible Performance. Many programming “best practices” taught today are performance disasters waiting to happen – https://www.computerenhance.com/p/clean-code-horrible-performance

Clean Code: The Good, the Bad and the Ugly – https://gerlacdt.github.io/blog/posts/clean_code/

Messy Code V/S Clean Code in MVC context – https://medium.com/highape-tech/messy-code-v-s-clean-code-in-mvc-context-9ad99079a4f8

What Is Clean Code? A Guide to Principles and Best Practices – https://blog.codacy.com/what-is-clean-code

Additional Resources:
Polymorphism in Java – https://www.geeksforgeeks.org/java/polymorphism-in-java/

From the blog CS@Worcester – Vision Create Innovate by Elizabeth Baker and used with permission of the author. All other rights reserved by the author.

The Importance of User Experience in Game Testing

While looking at internships I saw a couple of job postings for quality assurance at video game studios. Then I saw the qualifications and skills needed for the job. Then I started to look into the job. Looking at a couple of resources I noticed that this job has a couple of guidelines in order to help the video game have an amazing experience for players. These important concepts are called Functional evaluations, Regression assessment, User experience analysis. Within the job companies use Agile methodology to help QA teams to be able to solve upcoming issues throughout the game’s lifespan. 

This job requires employees to be skilled to fix technical problems and have critical thinking in order to solve problems. Let me explain the guidelines of game QA and why it matters. The first guideline is called Functional evaluations. Functional values is a series of tests that makes sure the game’s features and the game works as intended. 

Functional evaluations are divided into: 

  • Gameplay Mechanics: do player characters interact with objects correctly, can players use game mechanics correctly (for example special universal abilities), is character scale correctly.
  • User Interface: Can player controls activate certain buttons like pause, settings. Can players see certain features like health bars or ability cooldowns. 
  • Missions and Objectives: If a player completes a mission do they get a reward. Is it possible 
  • Multiplayer features: Can players join the server correctly and encrypted, etc…

Moving onto Regression assessments. It is to retest key features in the game after all patches have been implemented. The purpose of these tests is to

  •  Identify Vulnerabilities,
  •  Allocating Resources,
  •  Enhancing Reporting Accuracy. 

The reason why I mentioned these types of reasons for the tests is because they need to consider multiple factors in order to maintain customers’ enjoyment of the game. In addition, QA has to consider if the changes that could make the code be more complex, performance drops, user friction and costs. 

Moving onto the last point is User Experience Analysis. This issue can either make or break the success for a game. When players face some sort of friction like the game is not optimized for certain hardware or even constant disconnects to the server. As a result it will cause more players to return the game or stop playing the game entirely. I noticed that some games companies do not know how to filter through good suggestions and bad suggestions to fix in the next patch of the game. Regardless, that will take time for the company to set a clear roadmap on how they want to make their game.

From the blog CS@Worcester – Site Title by Ben Santos and used with permission of the author. All other rights reserved by the author.

More on Clean Code

For this quarter’s blog, I decided to research more into the book Clean Code by Robert C. Martin and found a blog discussing the good, the bad, and the ugly regarding the book. I chose this article because we have spent the last few classes working through POGILs related to the book. The author writes about how Clean Code has had its positive and negative impact on software development. For new programmers, the author highlights useful practices that are good for new software developers, such as good naming techniques, not repeating your code, and having functions only do one thing. On the other side, the author describes how the age of the book and its dated techniques can be considered obsolete. Clean Code was written over twenty years ago and is heavily focused on Java programming and outdated extensions that “[limit] the applicability for modern programming practices.” Another criticism by the author is that applying the rules of the book all the time can result in harmful code, such as excessive abstraction and code that is harder to maintain over time. The author argues that programmers should learn when these rules should be broken and apply them on a case by case basis.

This article was certainly helpful to give a further opinion on Clean Code and its subject matter. After going through the Clean Code POGILs in class, I had learned many things that I was not previously taught about programming. They were helpful to correct some bad practices that I was guilty of, such as commenting in place of poorly written code. However, some topics, such as the levels of abstraction or how to use classes and methods properly were initially confusing to me. It seems like the author also expresses similar frustrations in regard to these things. The author of the article describes any of the things from the book can be described in one phrase: “it depends.” Overall though, I felt it necessary to dive deeper into Clean Code for my own benefit. Even though I do not plan on pursuing a career in software development, many of these rules and structures can be applied to other disciplines within computer science and information related fields. When the time comes for me to work on a personal project or something needed for my career, I feel better equipped to handle such a task knowing what I know now. Even if some of the advice is dated, most of it can still be applied and result in better software development.

Original blog post: https://gerlacdt.github.io/blog/posts/clean_code/

, ,

From the blog CS@Worcester – zach goddard by Zach Goddard and used with permission of the author. All other rights reserved by the author.

From Ideas to Licenses: My First Deep-Dive into Software Licensing

This semester I finally sat down and untangled the confusing world of software licenses, starting from a basic question: what can you actually protect when you write code? One of the first things I learned is that you cannot copyright a mere idea for a program; copyright law only protects the concrete expression, like source … Read more

From the blog CS@Worcester – BforBuild by Johnson K and used with permission of the author. All other rights reserved by the author.

Understanding Code Review

Code reviews are a vital step in the process of putting out not only software but any form of work. This blog post by Kimmo Brunfeldt outlines the need for code reviews on projects as well as some of the best practices for them. The role of a code review is to share knowledge and ownership about the project among the team members as well as discuss development and do overall quality control. A standard flow can be seen as a draft, submission for review and suggested changes (A cycle between these steps often occurs), and then final approval and merging. Keeping this flow with positive feedback and clear and constant communication is key to consistent and good review.

The reasoning for choosing this topic was due to the recent topic of the class into the focus of clean code. This focus on clean code is a part of the process of code review as a key element of the review process as well as something to keep in mind during the writing of code. The ease of being able to not only read the code but how easy it is for someone else to understand it is vital for projects and a key aspect of code review. By having these group review sessions and collaborate with other people, it can help to have others look other the work and point out potential issues in naming or complexity.

The blog also gave some really great tips and ideas for me to use for future projects. Some of the best takeaways to implement were not only simple and obvious in hindsight, but ones that I myself often overlook in discussions and reviews of my work. The biggest thing I found to be key was keep constant code submissions small and concise so that quick review can be done and rapid feedback or implementation can be achieved. Along with this feedback should be given in a public setting or documented so that others can hear it or gain from it. These two statements were some the biggest takeaways that I found from the blog to apply to my own work as they are easy steps to take and implement in overall group work, however by doing these communication will not only increase across the entire project but also learning and overall scrutiny of the code in an easy manner that is not intrusive. Previous ways that I have seen or attempted include large sit downs or meets that often drag on but these seem to be much better alternatives that I look forward to trying.

Works Cited:

Brunfeldt, K. (2025, May 12). A complete guide to code reviews. Swarmiacom RSS. https://www.swarmia.com/blog/a-complete-guide-to-code-reviews/

From the blog CS@Worcester – Dan's Blog by Daniel Fung-A-Fat and used with permission of the author. All other rights reserved by the author.

Let’s Keep Expanding!!

In the workplace, not only do the number of projects continue to increase, but the way in which we approach them exponentially increases as well. Tech professionals are leading the way in developing cutting edge procedures and processes for daily work, tracking and planning. Tools rapidly evolve as well, so with that being said, project management has been a lot more interesting to say the least.

Adapting to new technologies and routines is the best way to be efficient. With the changes between roles and systems of project management, there needs to be some solutions (or at least one). According to the Forbes Technology Council, they have detailed emerging trends and strategies to inform various organizations. By counting off the actions in this list, we get to see an evolution within different companies and organizations if they feel encouraged enough to take them into consideration.

Starting off, project managers need to establish a V.M.O (value management office). It is the idea of shifting the focus from project delivery to value maximization. For example, if an organization has an initiative, they align it with different goals and efficient resource use to allow for continuous improvement. It is absolutely essential, especially in today’s climate of business and organizational behavior.

Never be afraid to rely on the professionals in times of need. This article highlights the importance of relying on “senior talent”. Since they have the broadened experience, they’re capable of making quick and well informed decisions. For more complex projects, this proves to be useful, helping project managers understand business goals by creating emphasis on exceptional product ownership skills.

I told you AI is not always a bad thing. A lot of individuals, including myself, believe in the power of AI being used as a tool. It’s no secret that several organizations use it, but it is very important to note how its being used. This is called resource optimization. By allocating these resources accordingly, complexities can be well more managed. Artificial intelligence can assist with communication, task automation and provide data insight, leading to greater outcomes/output.

For me, specifically reading just the title alone, I was thinking of more teamwork-driven strategies and trends, similarly to the SCRUM and Sprint conversations during lectures. Of course, I judged a book by its cover and I knew immediately that I had to read and dissect this story. It is important to acknowledge that this article is from a year ago, meaning that more and more trends have been created at this point. These strategies however are still very applicable to today’s modern climate of process management.

As a tech person, or any business person, it is crucial to stay optimistic and see the value in making changes. I believe that myself and my generation have the potential and resources to evolve areas in their career field, with ideas that we want to see unfold. It will be very interesting to see the growth.

Source: 20 Emerging Strategies And Trends In Project Management

From the blog CS@Worcester – theJCBlog by Jancarlos Ferreira and used with permission of the author. All other rights reserved by the author.

Code Reviews

I recently read the blog post titled “Why Code Reviews Are My Highest-Priority Work” by Jordan Edmunds. In the article, Edmunds explains why he regards code reviews as the top priority work. He outlines several reasons. First, that doing reviews early reduces the team’s merge conflicts and speeds up cycle time. He also notes that if a review happens soon after the author writes code, the author still has fresh context, making fixes and tests easier. He points out that timely reviews improve overall team productivity, and supports shared responsibility. He discusses common objections and shares how he integrates reviews into his day.

This blog post directly relates to our course topic of Code Review. I chose it because rather than just defining what code review is, Edmunds gives practical ideas into why it matters, based on real experience in a programming context. Since our course material covers this topic, this article provides a good example of how Edmunds’s code review ideas is applied. I felt it would help me connect theory with real practice.

Reading the article made me realize that code reviews aren’t just an after the thought thing to checkbox but a good practice for improving code quality. I learned that timing matters, a review done soon after code submission is far more effective than one delayed. I also like the emphasis on context, for the programmer, having fresh understanding of their changes makes review feedback much easier. These ideas provided by Edmunds helps shape how I think about code reviews now. I’ll aim to review often and hopefully the fresh context will help me pinpoint any and all problems present.

Personally, this article made me reflect on my own habits where I often skip reviews or wind up doing them late, when I encounter a problem running my programs. I’m now aware that this can slow feedback and especially development. After reading this blog, in any coding assignment or personal project, I plan to start reviewing written code quickly. Reviews are an important process which we upkeep standards, share progress, and improve code maintainability.

In summary, this resource has helped me understand the value of code review, and given me good ideas for applying it in team and personal works. By participating actively and thoughtfully in code review, I’ll hopefully write better code and contribute to smoother team processes.

https://medium.com/%40jordan.l.edmunds/why-code-reviews-are-my-highest-priority-work-8e9b4c410887

From the blog CS@Worcester – Coding with Tai by Tai Nguyen and used with permission of the author. All other rights reserved by the author.

Building Secure Web Applications

Title: Building Secure Web Applications

Blog Entry:

This week, I developed the issue of web application security- a growing serious field in the software development. With the growing interconnectedness of applications and the increasingly data-driven nature of the application development process, the importance of user information and system integrity is equal to the one of the functionality or performance. The subject is related to the course goals related to the design of systems, software quality, and secure coding practices.

During my research, I paid attention to the general weaknesses that programmers have to deal with, including cross-site scripting (XSS), SQL, and insecure authentication systems. Such weaknesses are usually brought about by a failure to look into security requirements at the initial design phase. As an illustration, the inability to check input correctly may enable attackers to inject bad codes or access classified information. Security by design is based on the idea that protection must be implemented at each stage of development instead of viewing security as an a posteriori.

I also reviewed the industry best practice of enhancing application security. The common attacks are prevented with the help of techniques like the parameterized queries, the enforcement of the HTTPS protocol and encryption of the sensitive data and the use of the secure authentication frameworks. Periodical code inspection, automated testing, and standard compliance, such as the Top Ten guide by the OWASP, make code developers responsible to the creation of more robust systems. I was also informed that a healthy security culture in a development team, wherein the whole team takes the responsibility of securing the data of its users, is as valuable as any technical measures.

This subject matter was echoed in our discussions in the classroom on software reliability and maintainability. Secure code is just like clean code in that the code will be used over a long period. I was intrigued by the fact that the same principles of design made it more secure such as the principles of clarity, simplicity, and modularity. A well-organized system, which is simple to audit, has fewer chances of concealing undetectable weaknesses.

Reflection:

This study has made me understand that the need to develop applications that are secure is not just a technical one, but also a moral obligation. The developers should be able to consider the risks and the safety of users in advance. Security should not be at the expense of usability but rather it should complement usability to produce software that the user can trust. This attitude has motivated me to follow safe coding practices early in my work which includes validating inputs, data handling and sound frameworks.

In general, this discovery broadened my perspective on contemporary software design to include aspects of performance and functionality. Security is a key component of quality software engineering like never before. With these principles combined, I am more confident that I will be able to create applications that are efficient and scalable, besides being user-safe in the ever-digitized world.

Next Steps:

Next time, I will test some security orientated tools in the form of penetration testing systems and auto vulnerability scanners. I will also consider reading more on OWASP guidelines as a way of enhancing my knowledge on emerging threats and mitigation controls.

From the blog CS@Worcester – Site Title by Yousef Hassan and used with permission of the author. All other rights reserved by the author.

Code Reviews: Writing Better Software Through Collaboration and Feedback

Hello everyone, and welcome to my third blog entry of the semester!

For this week’s self-directed professional development, I read the article “Best Practices for Peer Code Review” from SmartBear Software (smartbear.com). This article provides practical guidelines and research-backed insights on how to conduct effective code reviews in a professional setting. Reading it gave me a new appreciation for how structured review processes can transform not only the quality of code but also team communication and learning.

Summary of the Article

The article begins by explaining that code review is one of the most powerful tools for improving software quality. It cites studies showing that even small, well-structured reviews can significantly reduce bugs and improve maintainability.

Some key practices stood out to me:

  • Keep reviews small: Review no more than 400 lines of code at a time.
  • Limit review sessions: Spend no more than 60 minutes per review to stay focused.
  • Encourage collaboration: Authors should add comments and explanations to help reviewers understand their changes.
  • Focus on learning, not blame: Code review is most effective when it fosters shared ownership and continuous improvement.

The article also introduces metrics like inspection rate and defect rate, which can be used to measure how effective a review process is. Overall, the main message is that a good review culture combines process discipline with respect, clarity, and open communication.

Why I Selected This Resource

I chose this article because it connects directly to my real-world experience at The Hanover Insurance Group, where I worked as a PL Automation Developer intern. During my time there, code reviews were a core part of our workflow. Every piece of automation code had to go through review before deployment. I noticed that following consistent guidelines, like those mentioned in the SmartBear article, made a huge difference in maintaining quality and avoiding errors.

Since we’ve been focusing on software design and collaboration in class, this article helped me bridge what I’ve learned in theory with what professionals practice daily.

Personal Reflections: What I Learned and Connections to Class

Reading this article helped me connect classroom concepts like clean design, modularity, and readability with the real-world practice of peer review. At Hanover, I experienced firsthand how detailed feedback from senior developers helped me understand why small changes, like naming conventions or modularizing functions, mattered in the long run.

This article reminded me that code review isn’t just about technical correctness, it’s also about communication. Explaining your decisions helps others understand your design thinking, just like how UML diagrams or documentation clarify structure in class projects.

Application to Future Practice

Going forward, I plan to adopt SmartBear’s recommendations in both academic and professional work. I’ll keep my commits small, make my code clear and documented before review, and always focus on learning from feedback rather than defending my work. I’ve learned that humility and collaboration are just as essential to great software as technical skill.

Citation / Link
SmartBear Software. “Best Practices for Peer Code Review.” SmartBear, 2024. Available online: https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/

From the blog CS@Worcester – Rick’s Software Journal by RickDjouwe1 and used with permission of the author. All other rights reserved by the author.

Blog Post 2

Agile Principles: The Complete Guide To All 12 Principles For 2025

For this blog entry I decided to choose something related to Agile. In the blogpost, Agile Principles: The Complete Guide To All 12 Principles For 2025 written by Sean O’Connor, he goes over how Agile’s flexibility gives it real world benefits for businesses, development teams, and customers. Much like how with what we went over in class, Sean O’Connor explains that Agile’s strengths aren’t so much about speed of delivery of a product, but in it’s efficiency in producing a working project, with speed as positive byproduct. As someone who’s never been good at long term planning, what was explained in the blogpost really resonated with me. Things like catching problems early when it hasn’t become a core “feature” of the software, building what the customer actually needs rather then wasting time, and especially the part of creating quick wins, are some things that I value in a game plan. The blogpost then goes into 12 principles that makeup all Agile methodologies, a couple of which really stood out to me.

One of the principles was delivering working software frequently. I like the idea of real progress you can actually see and use, not just what it could potentially be. It’s nice when you get to see something that actually works early, even if it’s just a rough version. This approach makes more sense to me than spending weeks or months planning something that might not even be what was wanted, which is just a huge waste of time and energy. So to me being able to get instant feedback, learn faster, and fix problems before they turn into something major, is huge.

Another principle that ties into that is measuring progress by working software. That line really sums up Agile’s idea of “cutting out the chaff”. It’s easy to get caught up in planning, documentation, or presentations that sound good but don’t actually move the project forward. A working prototype says more than any report could. I think that same logic applies to class projects too, seeing your code actually run feels like a real measure of progress, not how well it’s outlined on paper.

The principle of simplicity, or “maximizing the amount of work not done,” also hit home for me. It’s about focusing on what truly matters and using just enough time and energy needed. I tend to overthink projects at the start, but this mindset reminds me that getting the essentials working is more productive than building unnecessary features. Fewer moving parts also means fewer ways for things to break (something I know all to well).

All in all, it’s reassuring to see that my “slacker mindset” can be the basis for something actually productive.

From the blog CS@Worcester – CS Notes Blog by bluu1 and used with permission of the author. All other rights reserved by the author.