MYCB: Readibilty and Testability
Acronyms make everything sound cooler or more important. That's why we programmers love it so much! MYCB stands for 'Making Your Code Better' which is the tag that I am going to use whenever I write something that might help you become a better coder (at least I hope so).
It has been just 3 weeks since I started for EBSCO Information Services and I have only worked on small-ish projects. And yet, I have learnt a lot! Every day is a day of learning for a junior dev! Don't get me wrong, I am not complaining. Getting better at programming is my primary goal right now.
During my projects, I have learnt one thing that stood out to me. You see, software are soft. They change all the time. Eighty percent of my time is trying to understand legacy code and I can bet that most, if not all, new hires have to go through the same thing. The code you write today will not only be read by your peers but also by someone like me starting their career and scratching their heads and going 'WTF is this?' every 30 second. Therefore, it is pertinent that you make your code readable. I have seen code where 3 or 4 conditionals are strung together using 'and' or 'or' , trying to fit everything into a single line. I will admit that there is a weird satisfaction when you can boil down 8 lines of code into 2, but it is not the smartest thing to do. Here is an example:
Even though both blocks of code give you the same result, the second one is a lot easier to read and understand. But it doesn't mean that you always deliberately write verbose code. Who likes reading a 500 lines class file?
You have to use your best judgement and decide when to explain your code or trim it down. I love ternary operators but in the aforementioned case, doing calculations on either side of the semicolon makes it ugly.
The second thing you need to keep in mind is making your code testable. This thing has been giving me a lot of pain. A lot of senior devs have told me to break my code down into testable chunks. Break it down to multiple methods so that you can write unit tests around it. For this reason, double check when making a method private. If you absolutely need it to be private, wrap it in a mock public method that you can test. Google how to make your code more testable. There are abundance of good books and resources dedicated to this topic.
The goal of this article is not a guide. I am just reminding you that readable and testable code is good code. As I encounter situations like this in the future, I will update the blog with more specific examples, and hopefully that will be more helpful.
* Code snippet taken from here.
Even though both blocks of code give you the same result, the second one is a lot easier to read and understand. But it doesn't mean that you always deliberately write verbose code. Who likes reading a 500 lines class file?
You have to use your best judgement and decide when to explain your code or trim it down. I love ternary operators but in the aforementioned case, doing calculations on either side of the semicolon makes it ugly.
The second thing you need to keep in mind is making your code testable. This thing has been giving me a lot of pain. A lot of senior devs have told me to break my code down into testable chunks. Break it down to multiple methods so that you can write unit tests around it. For this reason, double check when making a method private. If you absolutely need it to be private, wrap it in a mock public method that you can test. Google how to make your code more testable. There are abundance of good books and resources dedicated to this topic.
The goal of this article is not a guide. I am just reminding you that readable and testable code is good code. As I encounter situations like this in the future, I will update the blog with more specific examples, and hopefully that will be more helpful.
* Code snippet taken from here.
Comments
Post a Comment