Articles Referenced:
https://www.pluralsight.com/blog/software-development/10-steps-to-clean-code
Clean code is very important, especially in a group project. This assignment was a good reminder of the time and headaches that can be saved by being intentional with how I write code. I appreciated the article linked above from PluralSight because of its simplicity yet variety of suggestions.
The one that stuck out to me the most was Tip #7: “Remember the power of i”. This means to always use ‘i’ for iterating in a loop unless there already is variable named ‘i’ in an active loop. This helps make the code more readable, as any time you see an ‘i’ in use, you know that this corresponds to an outer (non-nested) loop.
The example shown below shows what NOT to do. I am certain that I have done this kind of thing in the past, and it is potentially confusing at a glance because it implies (by convention) that the first for loop has not terminated.
Instead, name both ‘i’ for extra clarity:
https://en.wikipedia.org/wiki/Code_smell
https://en.wikipedia.org/wiki/Technical_debt
Learning about code smells was also a very good experience for me because I had never heard of the term before. In order to learn the basics, I turned to the Wikipedia articles listed above.
Code smells refer to issues in the code that do not necessarily manifest in the form of a bug, but rather as poor or inefficient design. Code smells can be very dangerous because they might allow the software to function in its current form, but also produce technical debt. Technical debt is essentially trouble or difficulty that will arise in the future due to poor or hasty design.
One thing that learned to avoid from the TechTarget article was refactoring code before testing to see if it meets all use cases. This prevents you from wasting time refactoring code that does not even work in the first place. The point of refactoring code is not to improve the effect of the currently written code, but rather to improve its structure.
I am hopeful that we will not have to refactor code during our project, but it is definitely a possibility. If we do, it will be important that we understand the capabilities of the code as currently constructed before trying to refactor.
Leave a Reply