Challenge 11 "Your code took longer than expected to run."


#1

Multiple times when I was trying to get this challenge to work I was calling either lightCell() or convertColumn inside my for loop (lightCell for me calls convertColumn). This was totally valid, but since I have a complex convertColumn function (to accommodate columns of any size, i.e. column AAC) the repeated calls slowed my code down. The code should function fine but the stupid software limits said “Your code took longer than expected to run.”

I eventually worked out that I don’t need to convert the function inputs repeatedly inside the for loop, but really, this shouldn’t be the kind of inefficiency that slows down modern javascript enough to warrant failing a challenge.

This environment that doesn’t show outputs is really not the best for learning in. I’m rather disappointed in this setup and know a few people in my group have already quit because of it.


#2

I’m curious about how you implemented your convertColumn function. Did you have loops in there? Did your code run on other javascript compilers?


#3

Step one is some regex to remove any digits, so letters = input.replace(/\d/g,'');
Step two is a for loop that simply executes index = index+((parseInt(letters.charAt(i),36)-9)*Math.pow(26,letters.length-i-1));
The parseInt(,36)-9 gives the number of the alphabet, then the math.pow converts it to the proper decimal number from base 26.

With the test input of “C” for the column, the for loop in that function will only execute once (it cycles through the letters in the input).


#4

A nested for loop with very small iterations shouldn’t have killed the performance of your function. Thanks for sharing your algorithm. I went back and generalized my function using a loop and charCodeAt().

I agree that a compiler without an output window doesn’t help with learning. I had to use an online compiler to do all my work before copying and pasting my code to the lighthouse compiler.


#5

I don’t need to convert the function inputs repeatedly inside the for loop, but really, this shouldn’t be the kind of inefficiency that slows down modern javascript enough to warrant failing a challenge.

Just to offer the other side of the argument, I disagree strongly with your position. Inefficient coding like that is a real issue that may not cause a problem in itself, but if a coder thinks that coding like that is acceptable, they can cause issues in real projects. The simple fact is you shouldn’t be doing it, and it’s better to catch that now than let people think it’s acceptable.

I appreciate that the coding challenge accepts a variety of solutions allowing us to be flexible, but doesn’t accept clearly poor coding solutions, allowing novice coders to understand that inefficiencies like that are never acceptable.