In case you’re not familiar with HackerRank, it’s a platform for practicing coding, and, increasingly, it has become a platform for companies to test their engineering candidates. This is why it’s a problem that they’re encouraging people who practice with them or interview using their platform to write bad code.
function Rectangle(a, b) {
}
This is the starting point of a function they ask you to write for their 10 Days of Javascript. Creating a rectangle object is day 4 of those 10 days. Most coders will take this starting point as it is and fill in the space between the brackets. That’s probably what HackerRank expects you to do with their problems: leave the starting point they’ve given you as-is and fill in what’s missing.
If this is all they ever gave you, you could probably work out that a is one side of the rectangle and b is the other side. If you read the problem description, they’ll tell you explicitly that a is the length of the rectangle and b is the width.
Why All the Secrecy?
Batman needs to keep his identity secret. He spends his evenings breaking the law. Even though he’s doing it for good, he could still be arrested. In order to stay on the streets delivering vigilante justice, he can’t let anyone know that he is actually Bruce Wayne.
But, as far as I can tell, a and b don’t need to keep their true identities (the length and width of the rectangle) hidden. In fact, all they’re ever going to do in this function is be the length and width of the rectangle. That means they don’t even need to be a and b.
The names length and width are not reserved by Javascript. So, why not just call a spade a spade? Why can’t the length be length and the width be width?
Yeah, but What's the Harm?
In this HackerRank exercise, you’re going to write a few lines of code at most. Not to mention the only two logical parameters to create a rectangle and its length and width. You’re probably not going to permanently lose track of what a and b are. Even so, there’s still going to be a split second where you don’t know what a and b are.
This might even make you feel cool. Like you’re part of a fun club with a secret code. Muggles look at a and b and throw their hands into the air, but you… you can decipher it in a fraction of a second. It feels like a superpower. And if HackerRank does it like this, it must be right right way… right? !😰
In your career, you’ll never write an application that’s this short and that does so little. Imagine the split second it takes to remember what a and b are in the Rectangle function. Now put that in a context where the meaning of the parameters are not so clear. Maybe you have a function that displays an alert on your page. It takes three parameters: a, b, and c. Any idea what those parameters are? Yeah, me neither.
Now take this new naming issue and blow it up to an application with 10,000 lines of code. Each function has parameters with cryptic single-letter names. Since you learned this is OK, your variables are probably not thoughtfully named either. You’re going to spend most of the time you work on this application just trying to figure out what it does. I pity anyone else who has to pick this app up and work on it. I hope they have plenty of aspirin.
You might think I’ve cherry picked the only example or maybe the worst example of this on HackerRank. You’d be very very wrong. Not every exercise uses this opaque variable and parameter naming, but many do and some are even worse than my first example. Here’s your starting code for another indecipherable exercise:
'use strict';
process.stdin.resume();
process.stdin.setEncoding('utf-8');
let inputString = '';
let currentLine = 0;
process.stdin.on('data', inputStdin => {
inputString += inputStdin;
});
process.stdin.on('end', _ => {
inputString = inputString.replace(/\s*$/, '')
.split('\n')
.map(str => str.replace(/\s*$/, ''));
main();
});
function readLine() {
return inputString[currentLine++];
}
// Complete the minimumBribes function below.
function minimumBribes(q) {
}
function main() {
const t = parseInt(readLine(), 10);
for (let tItr = 0; tItr < t; tItr++) {
const n = parseInt(readLine(), 10);
const q = readLine().split(' ').map(qTemp => parseInt(qTemp, 10));
minimumBribes(q);
}
}
The variable naming in that main function is seriously making my head spin. t? tItr? n? q? qTemp? Why are these practice exercises not more readable?
Hey there. I help people like you start their web development careers. It starts with identifying a goal. Take my free course to get started! 🎉
Code Is For Humans
You may think that code is for computers. It’s not. Code is for humans. If it was exclusively for computers, we’d have no need for a high-level language like Javascript or Python.
Take this to heart as you’re writing your code. Write it to be read by someone other than you. Variable, parameter, and function names should encapsulate as much context as possible to help the reader understand what they’re reading. a is bad. length is good. lengthInInches is even better (if, in fact, you’re expecting the measurement to be in inches). If your code changes, make sure you update your names to reflect what they now represent.
It’s easy to look at HackerRank and, because they’re a huge, well-established, and, if the number of interviews administered through them is any indicator, well-respected site, assume they’re starting you out with good code. Unfortunately, that’s not the case.
If you practice on HackerRank, do yourself a favor and start your exercise by refactoring their terrible meaningless names to something that conveys the meaning and context needed to read the code. When you’re working on projects outside the platform, make sure their bad habits don’t poison your code and give you a reputation as a developer who writes indecipherable code.
By writing your code for the next developer coming behind you, you make it easy not only for other developers to work with you but for your clients to re-hire you and recommend you to other companies who need your help.
Oldest comments (34)
HackerRank also taught me how to write pretty clever code. Clever, unreadable, one-line code.
Now I'd rather write 3 lines of code and spend half a second reading the function than writing 1 line of code and spending 10 seconds to read what I was doing.
As you say, coding is for humans.
Agreed. Clever code makes you feel smart but doesn't do other the things that code should.
I feel stupid explaining code, so I tend the other direction. If I'm explaining then I feel like I did it badly and it's very embarrassing to me. Funny how we as humans see the same thing, but view it very differently.
I tried hackerrank and after two of those kinds of questions I quit for the simple reason that I didn't want to feel like an idiot. Opaque code is just tiring and IRL I always just ask. It's not worth my time doing it any other way.
Thank you so much for shining a light on this issue. It needs more attention and I thank you for taking the time to call them out on a very bad practice.
"Code Is For Humans"
Often forgotten, the interpreter/compiler doesn't care how you name things, your coworkers will.
I agree for the most part. I'm a huge advocate for responsible coding. Shoot, a huge part of Dead Simple Python is dedicated to it. More on coding challenges and good practice in a moment...
With that said, I think there is an exception for competitive code golfing (which I usually do over on Codingame instead of HackerRank), which I've found to be beneficial in a different way:
The goal of making the code as compact as possible forces me to understand the underlying processes and alternative ways of doing things. Brute-force seldom wins in length-based code golfing.
The same processes you should follow to make your code smaller in length-based code golfing are the same processes you would use in real world refactoring, although the outcomes are different. You always start by writing a simple, straightforward solution and verifying it works, and then you begin rewriting it piece-by-piece until it's a small as possible.
Time-restricted code golfing hones your ability to distill human thought (the prompt) into computer logic quickly and efficiently. In practice, this has helped me write better code in real world scenarios; it takes me less time to work out the logic, so I have more time to pay attention to matters of design and good practice. (After all, don't we usually skip good practice because of time?)
These unique benefits justify terrible variable naming practices in that specific context, so long as one remembers to use good names elsewhere.
None of that is to invalidate your concerns, of course. One should be aware of the profound differences between code golfing and real-world coding, and HackerRank doesn't always make that difference clear. Given its lack of time constraints, and the fact it isn't formal length-based code golfing (as far as I know), there's no reason why you shouldn't apply good practice to your code there! I literally always delete HackerRank's default code.
Personally, I do prefer Codingame, as it has proper multiplayer code golfing which is separate from the standard coding challenges. Their default code is almost always better, too.
Yep this seems right; HackerRank is closer to TopCoder, the goal is to pass the test and whatever other criteria there is. For HackerRank it's to pass the test and prove you can code to the interviewers. For TopCoder it's to pass the test and make the code as performant as possible.
I'm hoping that no one is really using either of those as a model for production code though!
I'm afraid people are taking those exercise starting points as models for how they should code because they don't know to be critical of them. Hope this post can reach at least a few of them.
Thanks for reading, Rudolf.
Gah, JavaScript is a language where so many things/opinions matter. It's pretty daunting at times. Thank you for this article! It's a good one :)
I was told early in my career to "code for the next developer after you" but also "imagine the next developer is a very big, angry man who knows where you live". Worked a treat, my naming and commenting is now explicit and verbose!
😆 I love that advice!
"Code is for humans." That is the strongest, and in my opinion, most important, point made in this article.
All code we write is made to be extended and improved by the people around us who, in many ways, would have a more clever way of extending and improving it. I am 100% guilty of rewriting functions myself if I can do it more quickly than I can understand what the previous developer was trying to. Not a great practice, I admit. But many times, an END PRODUCT is required that does certain things, to certain specifications, for a certain price, by a certain date. How clever the current codebase was is totally meaningless if it can be rewritten faster than extended. Don't let good code die when you leave. Variable, parameter, argument, function, class, and module names COUNT!! I want to work with the code I've been given. But I want to not have to explain delays to executive managment more. Just saying...😁😁🤪🤪
“There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.” — Leon Bambrick
I agree I'm the way that anyone writing about software development should be guiding others to be the kind of person that adds finesse to a team, not the one bringing speed bumps to the team. Help others create positive software engineer habits!
This is the part I hate the most. The problem description is so academic and pointlessly long. I have no CS background and find this off putting.