Hello everyone!
Welcome back, I hope everyone had a refreshing holiday season and got to spend some time recharging with family and friends.
My holidays were great! I got to spend some time with friends doing some winter hiking in Jasper National Park in Canada. It was cold but so beautiful seeing the Canadian Rockies with fresh snow and ice skating across frozen lakes!
Starting off the new year right, I’m back to working on my Senior Capstone project, Ops Normal. We have just officially moved into the full development cycle of the program and it’s looking like it’s going to be a busy term!
Let’s dive right into the technical stuff and talk about an important topic that doesn’t get enough attention: code smells!
Code has a smell?
Despite the visual imagery this term conjures, code smells actually refer to sections of code that were programmed poorly, or messy inefficient code!
We’re all guilty of it. We’re trying to rush through a project or reach a Sprint goal and have to submit a product on a tight deadline. We run the app and despite the iffy programming techniques it runs. Instead of going back and cleaning up the areas the that are redundant or don’t use best practices we just submit and move on to the next thing.
Why is this so bad?
Code smells leads to inefficient code, and inefficient code leads to what’s called technical debt; the cost of having to restructure and correct past mistakes in the code base. Technical debt can be a serious problem, especially for new software companies who don’t have the resources to dedicate development time to refactoring the code. Code base refactoring can be lengthy processes that take away from valuable development time that could be used to implement new features!
So, how do we avoid smelly code?
We can save ourselves SO much time but identifying good coding habits and implementing them as we write the code. This saves refactoring time, plus anyone else that has to work with your code will be very appreciative that you took the time to get it right.
Clean Coding Habits
So, what makes code clean exactly?
When we are coding, we want to avoid a couple things that can contribute to messy inefficient code, such as:
– Unnecessary duplicated code
– Long classes or methods
– Duplicating methods in different classes
– Blocks of commented out code
– And the list goes on…
For a full overview of clean coding habit here are some great sources:
– “Clean Code: A Handbook of Agile Software Craftsmanship” by Robert
C. Martin.
– “Refactoring: Improving the Design of Existing Code” by Mark Fowler
– Helpful website that breaks down common code smells
https://codeburst.io/write-clean-code-and-get-rid-of-code-smells-aea271f30318
In the example above, we have code logic that’s duplicated from one function to another. This duplicate code can cause the program to be unnecessarily bulky, so we can reduce the footprint by creating a separate function to perform this logic and calling it when needed.
After reading through these clean code articles and books, I’ve learned a lot about how I can improve my code and be more efficient in my programming! The biggest thing I’m looking forward to implementing during my capstone development is eliminating redundant sections of code and removing commented out code. I tend to comment out old code when I’m testing new features so that I don’t lose and code blocks I may need, but I recognize that I can be better by ensuring that all of these are removed before pushing any changes to the GitHub repo.
Clean coding habits specific to the Ops Normal project would be ensuring that my code abides by all the Dart/Flutter linting requirements. These requirements get updated from time to time, so it’s always good when we are working the code base to ensure that all our code still meets these stringent requirements.
One thing I’d like to avoid moving forward would be long methods! It’s easy to make one method and think how you can just put all the functionality you need in this one method, when instead it would be more efficient to create multiple methods to complete the task. I plan on evaluating all my methods to make sure they aren’t too long, and the logic isn’t duplicated from another method or class.
It’s going to be an exciting term, learning even more about Dart/Flutter and settling into the development workflow for the project. We’ll be adding the app to the iOS App Store & Google Play Store very soon, so we’ll be able to get real feedback from actual Wildland Firefighters on what they like/don’t like, what new features they could see as being useful, etc.
Much more to come on this exciting project, so stay tuned for what’s in store!
