Post-Break Excitement
Although Winter break was exciting enough on its own for me, our team is now getting into something real exciting with the development part of the capstone.
After we were assigned to our project, we only had a vague idea of what we wanted the end result to be. It’s super easy to get caught up in 1000 different ideas, only to realize that most of them aren’t realistic given our skills and available time.
I believe for all of us, this is the first full game we’ll be making. That’s equally daunting and exciting to me, as someone that’s always wanted to get into game development. This is a lot more formal compared to random programming projects where I could go at my own pace with no deadlines.
Despite the formalism of the capstone, I’m happy that I have a reason to be so motivated. Aside from the obvious benefits for a resume, I’m passionate about creating something I’m proud of. This is also a great opportunity to really get into a groove of working with a team and collaborative development.
We spent months planning how we’re going to create a great game. I expect there will be hiccups along the way, but I know my team can overcome them.
The first 1/3 of the capstone is down. It’s finally time to put all of that planning into action.
Clean Code and Code Smells
Now that we’re starting development, we need to think about how to keep our code “clean.” Regarding what exactly “clean code” means, I read the first chapter of Clean Code: A Handbook of Agile Software Craftsmanship by Robert “Uncle Bob” Martin.
Aside from some nice, broad ideas on what makes code “clean,” I appreciated reading this for its many viewpoints. Chapter 1 offers perspectives from many well-versed programmers on what it means to write clean code.
The main takeaway for me is that clean code is designed to be purely logical and immediately understandable. This means that no matter who reads that code, whether it’s future you, a newer programmer, or a seasoned veteran, it takes virtually no time to recognize what it’s purpose is.
A bad habit of mine that I’ve picked up on is to go for language-specific, “elegant” solutions when the opportunity presents itself. While this isn’t always necessarily a bad thing, it definitely detracts from the cleanness of code to go overboard with a certain quirk of Python.
A particular example of this where I tend to go overboard is with list comprehensions. Although it is a nice feature to have, it’s also easy to let it become an unreadable mess with bad variable names and odd formatting. I came across this example from my own code on a personal project from awhile ago:
image_layers = [
i
for i in [
self._visual_background_color_image,
self._visual_background_image,
self._visual_text_image,
]
if i is not None
]This is meant to be used to layer a few different elements into a single image, but it’s really not clear how it works from this alone. Refactoring this resulted in:
image_layers = [
self._visual_background_color_image,
self._visual_background_image,
self._visual_text_image,
]
image_layers = [layer for layer in image_layers if layer is not None]Although functionally the same, I find the refactored version to be much easier to read at first glance. This also has the benefit of avoiding nesting an entire list within a list comprehension, meaning adding extra layers won’t affect any understanding of what the list comprehension does.
In the future, and particularly for our capstone project, I’d love to stay aware of how readable my code is to help my teammates and future self out.
Moving onto code smells, this essentially refers to common problems that can show up while writing code. As with most things that smell bad, it’s typically something you want to avoid to begin with, but do something about when you come across it.
My favorite resource for learning about these is https://refactoring.guru/refactoring/smells, but I also read chapter 3 of Refactoring: Improving the Design of Existing Code by Martin Fowler.
There are many, many different code smells with their own causes and solutions. You can’t truly predict when they’ll appear, but you can take care to avoid the more egregious ones.
Refactoring Guru mentions 5 different types of code smells: Bloaters, Object-Orientation Abusers, Change Preventers, Dispensables, and Couplers. Regardless of the type, they all slow down programming at the end of the day.
A particular code smell that I believe I’ll need to watch out for in this project is too many comments: https://refactoring.guru/smells/comments.
I tend to be someone that almost never comments in code intended for myself, but go overboard in code intended for other people. I definitely need to find a balance of letting my code speak for itself, but highlighting the things that need explanation.
In the capstone project, I’m going to do my best to stick to obvious naming schemes and logically-readable code instead of comments. Comments should be reserved for those complicated pieces of code that can’t be made any clearer, such as heavy math and algorithms.
It is important to note that this does not include documentation, as we should be able to know what a method is meant for!
Conclusion
With Winter break and the Fall term gone, I know these next two terms are going to go by faster than I can blink.
I’m excited to see where our project ends up, but I’m going to do my best to savor the process along the way.