In my years as a programmer, I've come across some really really smart people who could create some very fancy code that (at the time) seemed to be the greatest stuff since sliced bread. But let me tell you, now that they have moved on in their careers and have left the company at which I currently work, I look at this code that I now have to support, and I shake my head.
You can learn more tips like this one and how to become a full stack Java developer at our Full Stack Java Bootcamp.
This code is too complicated!
What a nightmare, what first seemed like the level of coding talent I aspired to reach, now became the bane of my existence. So how could this be? How could I look at one piece of code one day and sing its praises, then the next be stating that it's causing me grief? I'm not sure what name to give to this other than the loss of context. When you are creating a particular piece of a software application, you are very familiar with all the bits and pieces of that part of code, because you're in the process of creating it. But if you allow some time to pass, you'll soon forget all of the ins and outs of the code you've already written. This will mean that if there's a bug in your code, you (or some other poor soul) will have to re-learn what that code does. So if that code isn't easy to read, interpret and follow, then you may end up pulling your hair out!
Keep It Simple Stupid (KISS)
This is the motto you should keep in mind when writing and designing your applications. Here's a wonderful quote that lends itself well to this motto:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand. – Martin Fowler
Writing code that can be understood by your fellow programmers is key, which is why if you're writing some code that you feel is a little complex when you're writing it, ask yourself
“If I came back and looked at this code in three months, would I be able to easily understand what's going on?”
If the answer to this question isn't a resounding and immediate “YES”, then you should take action to change your answer to an immediate and resounding “YES”.
How do I Keep it Simple Stupid?
Comment your Code
One way to make sure your code is easily understood by all, is to put in some comments that explain what any particular block of code is actually doing. This is fairly effective, but doesn't exactly guarantee that your code will be understood by all. Take this code snippet for example:
for( i = 0, j = 100; i < j; i++, j--)
What in the heck is this piece of code doing!? You could probably sit around for 10 minutes trying to figure it out, but, if I just add some comments before the
for loop, I could save you a lot of grief:
// count to 49
for( i = 0, j = 100; i < j; i++, j--)
Oh, I see! They are just counting all the way up to 49 and outputting each number in the console. Fair enough. This is effective, but what if someone were to change the code inside that
for loop and not update the comment to reflect what it is they've change? This is the downfall of relying on comments, they aren't always correct, and sometimes that can be more damaging to your debugging efforts than if they just hadn't commented the code at all.
But in any case, for the most part this tactic is useful and should be followed by developers. But, I've got one more neat way to ensure that your code is simple and easy to follow… and you may be surprised to hear it.
Believe it or not, I find that when I'm writing code and creating unit tests at the same time, this helps to keep the code simple. Why is that you ask? Well, I find that when I'm writing unit tests, the code has to be simple in order for it to be unit testable in the first place. The longer and more coupled a piece of code is, the harder it is to unit test. So if you write your code while unit testing it at the same time, a beautiful thing happens. Your code becomes less coupled, each method tends to keep to a reasonable size AND you've got a whole bunch of unit tests that help describe what your code does (through utilization of descriptive unit test methods, and expected results with your
Descriptive Variable Names
I cannot overstate the importance of being explicit with the names of your variables. Let me tell you the pain and eye gouging that goes on when I see a block of code that looks like this:
Date date1 = new Date();
Date date2 = x.getDateFromY();
Integer temp = 0;
Integer y = 30;
while (date1 < date2)
if (y < temp)
date2.setDay = x.getDay();
date1.setDay = y;
Seriously!? What the hell is going on here! It drives me mad when I see people naming their
date2, just name your variable after what it truly is! If I was assigned to debug this code, I wouldn't have a clue what the expected behaviour should be… but had the developers used more descriptive variable names, like
effectiveDateOfPurchase instead of
currentDate instead of
lastDayOfMonth instead of
y, I may have had a better idea of what's going on here.
Note: This particular block of code doesn't do anything, I literally just made it up on the spot to get my point across.
So, the point I'm trying to make here, is that you shouldn't be afraid of using a long variable name. Java won't get mad at you for having a variable name that's 20 characters in length. Plus, modern IDEs make it easy to track variables and rename them if they really do get too out of hand. But I am a firm believer that no seasoned developer would get upset with you if you were to use a descriptive name for your variables, because it really does help people understand what the code really does!
So, the most important thing you should take away from this discussion, is that you should KISS… Keep it simple stupid. Comment your code when you think people may get confused as to what it's doing. Unit test your code so there's less chance of your methods becoming unwieldy. And please, PLEASE, be descriptive when naming variables/methods. The world will literally be a better place if all developers followed these simple tips.
Oh, and if you feel like you've got a great example of some complicated code, or if you think you've got another great example of how to KISS, by all means, share your thoughts below in the comments section. I'd love to hear from you!
Keep It Simple Stupid… Sincerely,