Tag: CS 462

Categories
CS 462

The Project So Far

It’s almost the end of Winter term and our Furever Matchup application is finally coming together. In light of all the progress that’s been made so far, I’ll be answering some questions about the project and my role in it.

Why did you choose your project, and has it met your expectations thus far?

I liked the idea of combining technology with animal adoption because it makes the process more engaging and accessible. Initially, I expected the project to be more straightforward, but the complexity of handling different user roles and managing user interactions made it more challenging than I thought. Still, seeing the system come together has been rewarding.

What was the most difficult challenge, and how did you solve it?

One of the biggest challenges was implementing user authentication and role-based access control. Since the project involves different user types—adopters, shelters, and admin—each with varying permissions, setting up secure and intuitive access was tricky. I used Flask’s built-in authentication features along with role-based logic to ensure the right people had the correct access. I had to learn a lot about balancing security with ease of usability.

What would you do differently on your project and why?

I would set up clearer milestones and deadlines earlier. While we managed to get the core features working, some tasks took longer than expected, which led to a bit of scrambling near the end. Better-defined expectations from the start would have helped keep things on track.

Do you feel your project was managed well or poorly, and how would you change things?

Overall, it was managed pretty well considering our group had different tasks and schedules to work around. Aligning everyone’s progress was sometimes difficult, but we managed to get new releases out in time. Regular check-ins helped, but I think being able to work in-person could have made things smoother.

Did you initially have doubts about your ability to complete the project? How do you feel now?

I initially had doubts, especially since I didn’t have much experience working on a full web app from scratch. There were times when debugging authentication issues or handling database queries made me wonder if I’d get everything working in time. But now, I feel much more confident in my ability to break down problems and find solutions.

Who will use your project? Will it benefit them?

Since we’re not working with a project partner, this was more of a proof-of-concept project rather than something that will be actively used. However, if it were fully implemented, the primary users would be animal adopters and shelters. Shelters could list pets, while adopters could browse, favorite animals, and get updates. The goal is to make the adoption process more engaging and personalized, helping both sides find better matches.

How have you handled getting ‘stuck’ on the project?

I’d take a break, then approach the problem from a different angle—sometimes looking at documentation, asking for help, or debugging step by step. Also, explaining the issue to a teammate often helped me realize what I was missing. As a last resort, I would lay on the ground staring at my ceiling until I could work through the problem.

What are 5 things you learned from working on your project?

  1. User authentication is harder than it looks – Handling login, password resets, and access control took more planning than I expected.
  2. MongoDB requires a different mindset than SQL – Working with a NoSQL database changed how I thought about storing and retrieving data.
  3. Front-end planning matters – Mockups in Figma helped, but I underestimated how much UI/UX design affects usability. I would spend more time on the CSS styling than the actual code itself.
  4. Good documentation is essential – When switching between tasks, having clear documentation made debugging and collaboration easier.
  5. There are always bugs – No matter how much I tested something, I’ll see a bug that I missed in the presentation videos. Even when there are no bugs on my end, someone else running the application will find one I can’t reproduce, which makes debugging especially tricky.

Categories
CS 462

The Good and the Bad: Writing Clean Code

Writing code is an art unto itself, but writing clean code that is both maintainable and still makes sense is a skill that requires practice. I tend to focus too much on getting my code to work rather than being able to understand it at a later time. After reflecting on a couple of articles about clean code and code smells, I’ve identified some practices I’d like to adopt more often—and some habits I want to avoid.

What is Clean Code?

According to Soyak (2024), clean code is code that is “well-organized, easily understandable, and maintainable.” Writing clean code isn’t just about making it functional—it’s about ensuring that anyone (including your future self) can understand and modify it without undue effort. Soyak highlights several key principles, including:

  • Define variables close to where they are used.
  • Group closely related functions near each other.
  • Keep code lines short and focused.
  • Avoid horizontal alignment (lining up code across lines).

I’ve often aligned lines of code or comments because I find it visually pleasing. However, as Soyak points out, this practice can introduce unnecessary complexity. Misaligned spacing in different editors or environments can make the code look disorganized and can introduce problems down the line. Here’s an example: 

# Bad
variable1     = 10
variable2     = 20
total_value   = variable1 + variable2

# Good
variable1 = 10
variable2 = 20
total_value = variable1 + variable2

One other area I want to improve is grouping related functions near each other. In the past, I would simply list functions in the order I wrote them, making it harder to find and update related logic. By grouping functions logically, I can navigate and refactor my code more easily, especially in larger projects. For example:

# Grouped Functions
def validate_user(user):
    # Validation logic here

def save_user_to_db(user):
    # Database logic here

def send_welcome_email(user):
    # Email logic here

What are Code Smells?

On the other end of the spectrum you have code smells. Code smells, according to Kanjilal (2022), is code that is “inefficient, nonperformant, complex, and difficult to change and maintain.” These bad practices don’t necessarily break functionality, but they indicate deeper problems that could grow over time. Common examples include:

  • Duplicate code
  • Long methods
  • Over-reliance on comments
  • Data clumps

Duplicate code can creep in as projects grow, especially when I’m in a hurry to implement features. However, duplicating logic wastes time and makes maintenance harder. Instead, I want to reuse existing functions whenever possible. By reusing functions, I can avoid redundancy and reduce the risk of inconsistencies during updates.

Another thing I’d like to avoid are unnecessary or long comments. I try to comment my code so that I can understand what I was thinking when I wrote it, but the line between too much comments and not enough can get a little blurry.

# Unnecessary comment
count = len(users)  # This counts the number of users

# Self-documenting code
user_count = len(users)

Conclusion

By adopting clean code practices and avoiding common code smells, I can write software that is easier to read, maintain, and improve over time. I plan to focus on grouping related functions, avoiding horizontal alignment, eliminating duplicate code, and using meaningful names instead of excessive comments. Writing clean code isn’t just about following rules—it’s about building a foundation for better collaboration and future-proof projects.

References

Soyak, T. (2024, April 28). Clean Code: Definition and Principles — Part 3 (Last Part). Medium. https://medium.com/@tahsinsoyakk/clean-code-definition-and-principles-part-3-last-part-5a247d957c79

Kanjilal, J. (2022, March 11). Understanding code smells and how refactoring can help. Search Software Quality. https://www.techtarget.com/searchsoftwarequality/tip/Understanding-code-smells-and-how-refactoring-can-help