Why clean code
Code is read far more often than it is written, so write it for the next reader. This 10-line function works, but can you tell what calc(l, t) does? We will tidy it without changing what it does.
Refactoring means changing how code is written, never what it does. So first write tests: small checks that call the function with known inputs. Three carts give 108.0, 60 and 112.5. They must still pass after every change.
Refactor, line by line
The discount rule is written twice, once in each branch. Change one copy, forget the other, and you have a bug. Say it once, after the if: every cart still gets the same answer.
PEP 8 is Python's style guide. Put spaces around = and >, write one statement per line, and test a True/False value with if t:, not t == True. x *= 1.2 is short for x = x * 1.2.
calc, l, t and x tell the reader nothing, and PEP 8 warns that l looks like 1. Rename them order_total, items, add_tax and total. Unpacking each pair into price and qty replaces l[i][0] and l[i][1].
A magic number is a bare value with no name: what do 1.2, 100 and 0.1 mean? Name them in capitals, as PEP 8 does for constants: TAX_RATE, BIG_ORDER and DISCOUNT. Each is now defined in one place.
# set total to 0 only repeats the code, so delete it. A useful comment says why: the shop takes the discount after tax. The code can't tell you that, and someone might swap the two blocks.
order_total did two jobs: add up the cart, then apply tax and discount. Move the adding into a small function of its own, subtotal(items). Each function now does one thing, and both can be tested and reused alone.
Check and fix
Run the same tests again: 108.0, 60 and 112.5, exactly as before. That is the proof of a good refactor: the code changed shape, but every answer stayed the same.
A negative qty quietly gives a wrong total. Errors should never pass silently, so subtotal now raises ValueError. That changes behaviour, so it is a separate fix, made after the refactor, with a new test.
What changes
;; step 1/10 · read-more
the function, 10 lines, as found:
def calc(l, t):
x=0 # set x to 0
for i in range(len(l)):
x=x+l[i][0]*l[i][1]
if t==True :
x=x*1.2
if x>100: x=x-x*0.1
else:
if x>100: x=x-x*0.1
return x
it works; it is just hard to read
The refactor keeps the behaviour for the inputs the function is meant for: add_tax is True or False, and every item is a (price, qty) pair. For other values the two forms can differ (with add_tax = "yes", t == True is False but if add_tax: is true). x *= 1.2 gives the same result as x = x * 1.2, and 1 + 0.20 is exactly the same float as 1.2, so every answer matches to the last digit. Each version on the card is checked with python3.