Recently, I received yet another take-home assignment from a prospective employer. The assignment seemed easy enough till, of course, it wasn’t. I did my best and wrapped up the assignment within their time frame. Yep, I did not get the job and that’s okay. But after going through so many coding assessments, take-home assignments, and interviews, you start to wonder what am I doing wrong or how can I improve my game?
So, I asked my friend who’s already in the software industry to review my most recent take-home assignment. I explained the take-home assignment to him and what my approach was. My main question for him was how he would have done it differently. I was expecting a major tear apart of my code, but surprisingly his answer was “yeah, most of this looks fine” then comes the “but…”.
This “but…” has nothing to do with how I approached the assignment or how I structured the code. It was about the *drum roll* clarity of the code. I know most of my OSU cohort (and probably the majority of CS students) know this basic rule of not using a single letter as a variable name. And if you went through CS361+362: Software Engineering, you would probably also know to break your code down the length and widthwise. Simple enough right? But code clarity or “clean code” as most software practitioners would call it is much more than that.
After the review, the same friend messaged me the next day about a book he started to read titled Clean Code: A Handbook of Agile Software Craftsmanship. With the last quarter at OSU and several interviews online, I did not have the time to read 400 pages of text. But I found myself a copy and gave it a quick read anyway. I find myself hooked on the wealth of information on how to improve your code from the book. Below, I will give you some tidbits of what I found useful from the first 2 chapters of the book.
Class/Method Names
Classes and objects should be nouns and not verbs (ie. Customer, WikiPage). Methods, on the other hand, should be prefixed with verbs following whatever best describes what that method does (ie. employee.setName(), employee.getName())!
Make Meaningful Distinction
Sometimes you might have classes or functions that have a similar meanings. Therefore, you call them ProductInfo and ProductData. You might know the difference since you wrote the code. But if someone else reads this, that person would most likely not know what the difference are. Be distinguishable and specific when naming variables.
Use Pronounceable Names
Imagine you have a month/date/year variable. You can name the variable mmddyyyy which is fine but mentioning this variable’s name in a meeting would make you lose your sanity! We can simply name this as maybe timeStamp or dateOfPurchase!
Alright, I will stop my rant here. I hope you found this tidbit helpful or have ignited your passion for “clean code”. It has for me, and maybe I will write more of what I learned from this book in my future blogs. Let me know if you have heard of this book before. Apparently, it is quite popular according to Google.
-Justin
Leave a Reply