Ask HN: Can somebody explain HackerRank naming conventions to me?

1 points by logicalmonster ↗ HN
While not practical in ~98% of typical day to day web-development, I find most of the Leetcode challenges to be reasonably fair and straightforward coding challenges. The problems are written reasonably well to explain the challenge and they're formatted clearly so the task is usually easily understandable at a quick glance. When needed to explain a problem, there's sometimes a simple and clear graphic to help you visualize the problem. The variables and naming conventions used are reasonable and sane: problem input is usually something clear like: heights, target, s (for string), nums, etc. You can have some issues with individual problems, but for the most part, they're pretty decent problems. Some of the algorithms are frustrating and a real challenge to solve if you've never encountered anything like them before, but many of the problems are borderline fun because they're at least clear problems.

Hackerrank in contrast is written poorly. The questions are not formatted as nicely, which is the least important issue, but still an issue for quick comprehension of the problem. But what really drives me up the wall is their naming conventions for all of their problems. They use the most random and stupid input variables like n, c, k, m, x, a, b for all of their problems with seemingly no rhyme or reason. It makes trying to figure out what a problem is even asking for clearly and simply much harder and less fun than it should be.

1) Am I missing something obvious here? This is making me want to slam my head into a wall. Why would Hackerrank use a completely unclear mess of a naming system like this?

2) I'd be concerned about students learning bad coding practices from their examples. If you're naming variables with random names like c, q, l, m, z, t with no rhyme or reason, it makes code much more difficult to work with. This seems like an incredibly bad practice for the kind of site they are and the influence among younger programmers they might have.

0 comments

[ 3.0 ms ] story [ 11.6 ms ] thread

No comments yet.