The most common reasons people use functions wrong and don’t pass coursework questions#

Reason 1: Don’t override input values#

Here is a code to take 2 inputs, \(x\) and \(y\) and return x / y

def dividor(x, y):
    x = 6
    y = 2
    return x/y

Let’s try and run our code:

print(dividor(6 , 2))

3.0

Looks great, right?? However, when you submit the solution in our autograding platform, it says that you pass one test case, but not any others.

We get many coursework submissions like this, and unfortunately despite being almost correct, it scores very few marks. Why do you think this function would fail in our automated grading platform??

….

Let’s demonstrate a second case:

print(dividor(12 , 2))

3.0

Now 12/ 2 is 6 and not 3, so this is clearly incorrect. However, this function will only ever compute 6/2. It will always ignore whatever input values we give it. The lesson here is:

NEVER, EVER, IGNORE AND OVERWRITE FUNCTION INPUTS IN A FUNCTION

The solution to this would be:

def dividor(x, y):
    return x/y

Just deleting those middle two lines. The function does not choose it’s input values, they are provided to the function.

print(dividor(12 , 2))
print(dividor(6,2))

6.0
3.0

Reason 2: No return statement (or print instead of return)#

There’s two ways this crops up, either someone writes a function with no return

def dividor2A(x, y):
    z = x/y

Or someone writes a function with a print in place of a return

def dividor2B(x, y):
    z = x/y
    print(z)

In both cases the function will fail:

print(dividor2A(6 , 2), 'no return')
print(dividor2B(12 , 2), 'print instead of return')

None no return
6.0
None print instead of return

However, using a print can be confusing as the right answer is being printed to the screen. But something printed to the screen is only on the screen, and cannot be used, so if we do:

answer = dividor2B(12 , 2)
assert(answer == 6.0)

6.0

---------------------------------------------------------------------------
AssertionError                            Traceback (most recent call last)
Input In [9], in <module>
      1 answer = dividor2B(12 , 2)
----> 2 assert(answer == 6.0)

AssertionError:

The code fails.

Again the right solution is a return statement.

def dividor2(x, y):
    z = x/y
    return z

ALWAYS REMEMBER YOUR RETURN IN A FUNCTION. WHILE print CAN BE USEFUL FOR DEBUGGING, IT WILL NOT BE USEFUL FOR MUCH ELSE. REMOVE print STATEMENTS BEFORE SUBMITTING SOLUTIONS

Reason 3: Using input#

The input function should never be used in your coursework. It won’t work, and the system will just say “code doesn’t work”.

An example of this is:

def dividor(x, y):
    x = input()
    y = input()
    return x/y

We are hoping to see less of this this year, as we have de-emphasized this function a lot.

Reason 4: Your code is broken#

Someone might submit a code to divide two numbers that looks like this:

def dividor(x, y):
    return x*y

How would you go about analysing this and seeing where the problem is? We have a lesson in week 7 where we will go over this in detail, but at this stage:

  • Carefully read over your code. Write down what you think each line is doing. Is it doing that?

  • Use print statements to figure out what the code is actually doing at each step.

  • If you’ve gone through this, ask one of us. Come to a drop-in class, or ask in class. We cannot give you solutions to coursework questions but we can guide you in debugging your own code.

Reason 5: The system is broken#

I do get a number of emails each year saying “My code doesn’t work in HackerRank, but does work for me, HackerRank is broken”. Some things to remember if you’re going down this line:

  • HackerRank is not different from Colab. You do not need to write a solution in Colab and copy it across (though some may want to do this). You can print, debug, and do whatever you want within HackerRank.

  • In 90% of emails like this, the issue is “Reason 4”. Do carefully check over your code.

  • However, while we do test coursework questions, we can make mistakes, and there have been instances where solutions are right, but do not pass. We are always happy to check cases like this and at least let you know if a problem is on your end (or fix the question on our end if not).