The beginning of this term marks the beginning of new goals in the senior capstone. Previously, a lot of planning and brainstorming took place to determine the viability of our application, “A Text Adventure Game for Education”. Currently, more of our effort is placed into assigning tasks on Trello and committing code for our respective fields within the app.
Regardless of current knowledge, it’s always important to brush up on syntax, packages, and more effective means of working with teammates. As such, I decided to review some best practices in writing clean code and some things to avoid “code smells”.
Clean code covers everything from naming variables reasonably and legibly to using comments to clearly explain what each section of code accomplishes. Good naming practices for variables allows teammates as well as myself to interpret the function of a variable even without a comment. Oddly enough, comments can be in excess in cases where the line or section is self-explanatory. In cases where things need to be modified or given particular attention, there is no replacement for them.
RisingStack caught my interest with a list of do’s and don’t’s for best practices in coding. Creating variables that are easy to pronounce is something I often fall short on and see a lot in other’s code as well. For example [1]:
// DON’T
let fName, lName
let cntr
let full = false
if (cart.size > 100) {
full = true
}
// DO
let firstName, lastName
let counter
const MAX_CART_SIZE = 100
// …
const isFull = cart.size > MAX_CART_SIZE
I have a tendency to use short names that make sense at the time which can remove some meaning and make them more difficult to communicate.
Poor coding practices or, “code smells” on the other hand are defined by Testim as, “any characteristic in the source code of a program that possibly indicates a deeper problem” [2]. The simplest example provided by them is the incorrect usage of equality in JavaScript. Using ‘==’ and ‘===’ accomplishes two different things and should be used as such. ‘==’ might result in “true” when a string is compared to an integer where the intent is to only return “true” if two equal integers are provided.
While I can’t say I dislike their methods, the developers of the game “The Simpsons Hit & Run” had some… Interesting comments in their code. Feel free to check out the video going over some of the highlights here:
https://www.youtube.com/watch?v=R_b2B5tKBUM
As we continue to push changes to our code constantly I’m sure our team will encounter new problems and solutions to ensure we avoid some code smells and attempt to avoid what I’ll call for the sake of this post the “Simpson’s Pitfall” in commenting.
