Category Archives: Blog Quarter 2

DESIGN SMELLS AND PATTERNS: WHY QUALITY CODE MATTERS

Writing code involves more than just making it functional, it focuses on creating solutions that are understandable, maintainable, and flexible. Yet, as deadlines approach and requirements change, our codebases frequently reveal subtle indicators that they may not be as robust as they appear. These indicators are commonly referred to as code smells and anti-patterns. In this blog today, we will explore the meanings of these terms, their significance, and how software developers can begin to identify and tackle them in their own projects.

What Are Code Smells vs Anti-Patterns?

A code smell is like a little red flag. It doesn’t necessarily mean your code is broken, but something might be off. Think of it as an indicator of hidden trouble.
An anti-pattern is a commonly used approach or structure that seems reasonable but tends to lead to problems. It’s like following the “wrong recipe” because it looks familiar.
In short, we shall term code smells are symptoms and anti-patterns are traps. Recognizing both helps keep your codebase healthy, especially as your projects grow or you work with others

Five Common Code Smells

Here are five code smells to be aware of, along with simple examples:

1. Duplicated Code

If you notice the same logic appearing in multiple locations, that’s a code smell. For example

def calculate_area_rectangle(length, width):
return length * width

def calculate_area_square(side):
return side * side

Here, calculate_area_square merely duplicates logic. Duplicated code complicates maintenance if a bug is present in one instance, it is likely present in others as well.

2. Large Class / Method

When a class or method attempts to handle too many responsibilities, it becomes difficult to comprehend, test, or maintain. For example, a User class that also manages discount calculations breaches the single responsibility principle. Instead, that functionality could be placed in a separate DiscountCalculator.

3. Long Parameter List

These are methods that require numerous parameters are harder to read and invoke correctly. For example:

def create_user(name, age, address, phone, email, gender, occupation):
pass

Organizing related parameters or encapsulating them within an object can simplify the process.

4. Feature Envy

When a method in one class predominantly interacts with the data of another class, the logic likely belongs in the latter. For example, a get_full_address method in the User class that extensively accesses data from the Address class should probably reside in the Address class.

5. Data Clumps

This refers to a collection of variables that consistently appear together such as street, city, state, postal code and indicates a lack of abstraction. Instead, they should be grouped into an Address class or struct. Having ungrouped data results in redundancy and inconsistencies.

Common Anti-Patterns to Avoid

Here are several prevalent anti-patterns and the reasons they pose risks:

1. Golden Hammer

Dependence on a familiar tool due to personal preference, even when it is inappropriate for the task at hand. For instance, utilizing a list comprehension for side effects such as printing in Python solely because of a fondness for list comprehensions.

2. Cargo Cult Programming

Imitating structures, patterns, or frameworks that you have observed without comprehending their purpose or applicability. For example, incorporating a decorator in Python that serves no significant function merely because other code examples included decorators.

3. Analysis Paralysis

Allocating excessive time to planning, resulting in no actual progress. While planning is beneficial, there comes a time when one must construct, test, and iterate. Over-analysis can hinder advancement.

4. God Object

A class or module that encompasses all functionalities—managing data, processing, displaying, logging, etc. This centralization undermines modularity and increases the risk associated with changes. An example would be a SystemControl class that logs errors, saves data, processes data, displays data, and so forth.

5. Spaghetti Code

Code lacking a clear structure or modularity, characterized by numerous nested loops and conditionals. This complexity makes debugging or extending the code exceedingly challenging. An example includes deeply nested if statements and loops within a single function.

Here’s why you should care as a aspiring developer or even as someone interested in code;

When you write code applying these ideas makes your work cleaner, more maintainable, and often higher quality.
When you show up for internships or team projects, knowing about code smells and anti-patterns gives you a professional edge,you’ll write code that is easier for others to work with. If you eventually lead or participate in code reviews, you’ll be able to spot and explain refactoring opportunities and not just “it works”, but “it works and is maintainable”. As your projects grow, technical debt can bite hard. Early awareness helps you avoid getting overwhelmed by messy code in bigger projects.

Conclusion

Recognizing code smells and anti-patterns isn’t about perfection, it’s about awareness and intentional improvement. By spotting the subtle indicators, you give your codebase and yourself a chance to evolve gracefully rather than crumble under its own complexity. If you want to take a next step: pick one small project maybe an assignment, or one module of your Android app and identify one smell you can fix. Refactor it. See how your code feels afterwards. Because when you clean up smells and avoid traps, your code becomes more than just a working program it becomes something you’re proud of.

References:

https://blog.codacy.com/code-smells-and-anti-patterns

From the blog CS@Worcester – MY_BLOG_ by Serah Matovu and used with permission of the author. All other rights reserved by the author.

Understanding the Twelve Principles of Agile Software

The 12 Principles of Agile Software explained

For this professional development entry, I chose to read the article titled The Twelve Principles of Agile Software Explained from the Agile Alliance website. The article provides an overview of the core ideas that shape the Agile Manifesto and explains how they guide the way modern software is built. What immediately caught my attention was how the principles focus on people, teamwork, and adaptability rather than strict processes or heavy documentation. The article highlights that Agile is not simply a development framework but a philosophy centered on collaboration and continuous improvement. It emphasizes that successful teams listen to their customers, respond to change quickly, and work together to deliver valuable software frequently rather than saving everything for one big release.

I found this resource helpful because it connects directly with what we have been studying in CS-343 about software processes and team communication. In many group projects, I have experienced situations where rigid planning or lack of communication slowed progress. Reading this article helped me see that Agile’s emphasis on flexibility and open dialogue could have prevented some of those problems. The principle that stood out to me most was “responding to change over following a plan.” This idea made me realize that while planning is important, being adaptable is even more valuable. Real-world projects rarely go exactly as expected, and being able to adjust quickly is a skill that separates good teams from great ones.

Another key takeaway for me was the focus on sustainable development. The article explained that teams should maintain a consistent pace and avoid burnout, which is something I think every computer science student can relate to. It is easy to fall into a cycle of late nights and last-minute fixes, but this principle reminded me that long-term quality depends on balance and discipline. The principle about motivated individuals also resonated with me. It stated that the best results come from trusting team members and giving them the environment and support they need to succeed. I have noticed this in my own coursework; when everyone feels respected and valued, collaboration becomes smoother and creativity increases.

The article also touched on the importance of reflection, encouraging teams to pause regularly to discuss what went well and what could be improved. This aligns perfectly with the concept of continuous improvement that we discuss in class. I learned that retrospectives are not just about fixing mistakes but about strengthening the team’s process as a whole. Moving forward, I plan to apply these ideas in future projects by promoting open communication, being willing to adjust plans when needed, and supporting my teammates in maintaining a healthy work rhythm.

Overall, this resource gave me a deeper understanding of what it truly means to work in an Agile environment. It showed me that Agile is not about speed but about building smarter, more collaborative, and more human-centered teams. The twelve principles serve as a strong foundation for both professional development and teamwork, and I believe they will continue to guide me as I grow in my career as a software developer.

From the blog CS@Worcester – Life of Chris by Christian Oboh and used with permission of the author. All other rights reserved by the author.

Learning More About Design Patterns

Recently I have been learning about Design Patterns. I was specifically taught Strategic Patterns. It is a pattern that defines a family of algorithms, summarizes them, and then divides them up into understandable sections. In this type of pattern, there will always be at least one context connected to a strategy and a strategy connected to its subsections. This pattern also allows for choices in implementation which makes it perfect to have if your code needs to take any deviations due to a client. It is also good for anything that deals with a family of related algorithms, and anything that wants to avoid subclassing and conditional statements. This is good since conditional statements cause unnecessary nesting and put extra weight on the code and subclassing makes the code difficult to handle in the long run due to making it brittle. With this known, it is understandable why many utilize Strategic Patterns.

Now, I have demonstrated knowledge in strategic patterns but why stop there? There are many other pattern categories worth exploring.

To delve deeper into the topic, I used this website: https://sourcemaking.com/design_patterns

This website explains a few design patterns such as: Behavioral, Structural and Creational. It explains them in a beginner friendly manner, which is the main reason I chose it. It also defines what a Design Pattern is and the cons of using Design Patterns.

The first thing I learned about was Creational Design Patterns. This pattern focuses on class instantiation which allows you to use the blueprints defined by a class to create objects with specific states and behaviors. Let’s say you need to create a class that holds all existing employees. With class instantiation, you need to add is needed information such as name, email, department. Then, all you would need to do would be to give the employee attributes and the code would sort itself making sure that employee information would be sorted into the exact format you desire. In general, Creational Design Patterns specialize in making this a seamless process for your code.

The next thing I learned was Behavioral Design Patterns. It focuses on class objects’ communication. Sometimes one class needs information from another to initiate, terminate or do a specific task. Behavioral Design Patterns is designed for that. It possesses a chain of responsibility and makes sure each link in that chain runs smoothly. The code depends on it since if one class goes wrong, the others would follow.

To conclude, there are many ways to do Design Patterns. Each have their own purpose and specialties. It was interesting to learn about a few of them, and I wonder if I will have to utilize one in the future. Nevertheless, it was interesting to learn about.

From the blog My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.