Readability of code
Some say that you do not need comments and your code need not be readable if you are a professional.
To be more specific, the Facebook post by my employer, 99X Technology and the subsequent discussions in the comments section got me thinking. So here’s what I think. First and foremost, that statement is just wrong, as wrong as driving on the wrong side of the road!
In my opinion, properly commented and readable code should be the hallmark of a professional. I first started writing code in Grade 9, some VB here and some HTML there. At that time, I was more interested in seeing the result on the screen. As you can imagine, it was barely documented and was for the most part, spaghetti code.
Unfortunately I do not have a sample of the wonderful code I wrote back then. However, a year back I happened to stumble upon an application I wrote when I was at IIT along with a few friends for a competition. It was an Augmented Reality application written in JavaScript. I ran the app a few times and was proud of myself and my teammates and what we had achieved as undergrads. Naturally after toying with the app, I went into the code, with the idea of improving the application.
Et voilà! (this is just one function, but you get the gist)
As you can see, the above snippet is quite interesting, dotted with magic numbers, oddly named variables and commented lines of code. I spent 2 hours trying to make sense of the code I had written but to no avail, sadly I ditched my plan to make my app great and proceeded to make my way to the local watering hole.
Today, I work in a team with 5 developers in addition to myself on a codebase that is 3+ years old written in C# and JavaScript. We follow a strict coding standards for both languages. Each pull request is checked against the said standards, along with checks for comments and readability. A pull request is not merged if the reviewer finds that the code deviates from our standards (e.g. magic numbers, hard coded values or unreadable code). We even have a defined comment format which has the name of the developer and the date commented. We see it as our duty to write good maintainable code such that it will be a help to the next guy working on it. In an event the logic changes, the comment is updated as well.
I personally feel that the above mentioned practises have helped us deliver a quality product to our customer.
In my humble opinion, writing comment less, barely readable code is a right of passage from novice to expert. For instance, when you are an undergraduate learning to program for the first time, your code can afford to be unreadable as long as it works. However, your code writing has to evolve, much like we humans evolved.
Well, that was my 2 cents worth!
Cheers!
For more from Sabry, check out his writing on Medium
