Best Coding Practices

Best Coding Practices | Algoryva

Worked by hand

The edge-case checklist, applied

For a function that takes a list of numbers, run through these inputs before you submit. For each, decide what the *right* answer is, then check your code gives it.

input	why it matters	typical failure
[] (empty)	loops do not run; `a[0]` and `max(a)` crash	IndexError, ValueError
[x] (one item)	neighbour loops like `a[i + 1]` run out of range	IndexError, wrong answer for n = 1
all values equal	strict versus non-strict comparisons	counts of 0 or n instead of the right one
already sorted / reverse sorted	best and worst cases for many algorithms	slow, or fails to move anything
negative numbers and zero	assumptions like “max starts at 0”	wrong maximum when all values are negative
maximum size from the constraints	speed and overflow in other languages	time limit exceeded
duplicates	sets, `remove`, strict comparisons	items lost or counted twice

1
Decide the expected answer first
If you run your code and *then* decide whether the output looks right, you will talk yourself into it. Write the expected result before running.
2
Test the boundaries of every loop
For each range, ask: what are the first and last values of the loop variable, and are they the first and last items I intend?

Implementation

Reading input and writing output

Contest input is plain text. Reading it correctly, and quickly enough, is the first step of every solution. The snippet below *simulates* the input with io.StringIO; in a real contest it comes from the keyboard or a file.

python

import io
import sys

sys.stdin = io.StringIO("3\n5 8 2\nhello world\n")   # simulates what a contest feeds your program
input = sys.stdin.readline

n = int(input())
nums = list(map(int, input().split()))
text = input().strip()
print(n, nums)   # 3 [5, 8, 2]
print(text.split())   # ['hello', 'world']

sys.stdin = io.StringIO("2 7 1 8\n")
data = sys.stdin.read().split()
print(list(map(int, data)))   # [2, 7, 1, 8]

Reading the code

›input = sys.stdin.readline replaces the built-in input with a faster line reader. For a million lines this can be several times faster than the default. It keeps the trailing newline, which int(...) and .split() ignore but .strip() removes if you need the clean text.
›A typical first line holds a count n, and the next line holds n numbers: list(map(int, input().split())).
›sys.stdin.read().split() reads everything at once into one list of words. Convert as you consume them: handy when the layout is just “a lot of numbers”.
›Match the output format exactly: spaces, one answer per line, upper or lower case (YES is not Yes). For many lines, collect them in a list and print once with "\n".join(...), which is much faster than many print calls.

Implementation

Tests you can run in one second

An assert stops the program with an error if its condition is false, so a block of asserts is a test suite. Put them right after the function while you are developing.

python

def is_palindrome(s):
    cleaned = [c.lower() for c in s if c.isalnum()]
    return cleaned == cleaned[::-1]

assert is_palindrome("")                      # empty
assert is_palindrome("a")                     # single character
assert is_palindrome("A man, a plan, a canal: Panama")
assert not is_palindrome("race a car")
assert is_palindrome("12321")
print("all tests passed")   # all tests passed

Reading the code

›The comments next to each assert say *why that case exists*: empty, single character, punctuation, a negative case, digits.
›If any assert fails, Python reports the line, so the failing case is obvious. If all pass, the final line prints.
›Write the edge cases first. They are where the surprising answers live (is the empty string a palindrome? Here we chose yes, and wrote it down).

Implementation

Finding a bug on the smallest failing input

When a solution is wrong, resist re-reading the whole program. Instead shrink the failing input until it is tiny, then trace it by hand. The buggy function below agrees with the correct one on the first input and disagrees on the second.

python

def count_below_buggy(a, t):
    c = 0
    for i in range(len(a) - 1):          # BUG: the last index is never visited
        if a[i] < t:
            c += 1
    return c

def count_below(a, t):
    c = 0
    for x in a:
        if x < t:
            c += 1
    return c

print(count_below_buggy([5, 1, 9], 6))   # 2
print(count_below([5, 1, 9], 6))   # 2
print(count_below_buggy([1, 2, 3], 10))   # 2
print(count_below([1, 2, 3], 10))   # 3

Reading the code

›range(len(a) - 1) stops one short: the last index len(a) - 1 is never visited. On the first test both versions return 2: the bug is hidden because the skipped last element (9) was not below 6 anyway, so skipping it changes nothing.
›The second test, where every element qualifies, exposes it: the buggy version misses the last one and returns 2 instead of 3.
›This is why “all equal” and “all satisfy” inputs belong on your checklist: they are the ones that make boundary mistakes visible.
›The fix also removes the index entirely (for x in a). Fewer indices means fewer chances for off-by-one.

Implementation

Stress testing: trust, but verify against brute force

For a fast, clever solution, write also a slow version that is so simple it is obviously right. Then run both on hundreds of small random inputs and compare. Any disagreement is a bug, and the printed input is a ready-made small failing case.

python

import random

def max_subarray_fast(a):
    best = cur = a[0]
    for x in a[1:]:
        cur = max(x, cur + x)
        best = max(best, cur)
    return best

def max_subarray_brute(a):
    return max(sum(a[i:j]) for i in range(len(a)) for j in range(i + 1, len(a) + 1))

random.seed(7)
for _ in range(500):
    a = [random.randint(-9, 9) for _ in range(random.randint(1, 8))]
    assert max_subarray_fast(a) == max_subarray_brute(a), a
print("500 random tests agree")   # 500 random tests agree
print(max_subarray_fast([-2, 1, -3, 4, -1, 2, 1, -5, 4]))   # 6

Reading the code

›max_subarray_brute tries every start and end: slow (O(n³) as written) but impossible to get wrong. max_subarray_fast is the one-pass method.
›random.seed(7) makes the run repeatable, so a failure can be reproduced.
›assert fast == brute, a stops on the first mismatch and prints the offending list a.
›Small sizes (1 to 8 items, values -9 to 9) are deliberate: bugs show up on tiny inputs, and tiny inputs are easy to trace by hand.
›The last line checks one known answer: for that classic array, the best contiguous sum is 6.

Worked problem

Spot the off-by-one

The problem

A function should count how many numbers in a list are smaller than t. It returns the right answer, 2, for count_below_buggy([5, 1, 9], 6), but a teammate says it is wrong. Find the failing input and fix it.

Think about which inputs are affected by the loop bound. range(len(a) - 1) skips the last index.
The bug is invisible unless the last element should be counted.
Construct the smallest input that exposes it: a list where every element is below t, such as [1, 2, 3] with t = 10.
Fix by looping over the items directly.

python

def count_below_buggy(a, t):
    c = 0
    for i in range(len(a) - 1):          # BUG: the last index is never visited
        if a[i] < t:
            c += 1
    return c

def count_below(a, t):
    c = 0
    for x in a:
        if x < t:
            c += 1
    return c

print(count_below_buggy([5, 1, 9], 6))   # 2
print(count_below([5, 1, 9], 6))   # 2
print(count_below_buggy([1, 2, 3], 10))   # 2
print(count_below([1, 2, 3], 10))   # 3

Takeaway. Choose test inputs that make the *boundary item matter*. The first sample agreed because its last element was not supposed to be counted anyway. “All items qualify” is a cheap input that exposes many boundary bugs.

Worked problem

Stress test a clever solution

The problem

You wrote a one-pass solution for the maximum sum of a contiguous subarray. How can you gain confidence it is correct, without trusting your own reasoning?

Write the simplest possible version that tries every subarray: slow, but easy to verify by eye.
Generate many small random arrays (including negatives, since “all negative” is a classic trap).
Assert that both functions agree on each; a failure prints the exact input.

python

import random

def max_subarray_fast(a):
    best = cur = a[0]
    for x in a[1:]:
        cur = max(x, cur + x)
        best = max(best, cur)
    return best

def max_subarray_brute(a):
    return max(sum(a[i:j]) for i in range(len(a)) for j in range(i + 1, len(a) + 1))

random.seed(7)
for _ in range(500):
    a = [random.randint(-9, 9) for _ in range(random.randint(1, 8))]
    assert max_subarray_fast(a) == max_subarray_brute(a), a
print("500 random tests agree")   # 500 random tests agree
print(max_subarray_fast([-2, 1, -3, 4, -1, 2, 1, -5, 4]))   # 6

Takeaway. Five hundred random tiny tests catch most bugs in seconds. The brute force does not need to be fast, only *obviously right*. Once they agree, you can trust the fast version on large inputs.

Wrap-up

Remember this

Clear names, small functions and comments that explain why prevent bugs before they exist.
Boundary mistakes (off-by-one) cause most “passes the sample” failures. Check the first and last value of every loop.
Read input quickly (sys.stdin) and match the output format exactly.
Test with a checklist of edge cases, and write the expected answers before running.
Debug by shrinking the failing input; verify fast solutions with a brute-force stress test.

Cheat sheet

Before coding: re-read constraints + output format; list edge cases
Edge cases: empty · one item · all equal · sorted · negatives · max size · duplicates
Fast input: input = sys.stdin.readline · or sys.stdin.read().split()
Fast output: print("\n".join(results)) once
Debug: smallest failing input → trace variables on paper
Verify: brute force vs fast on 500 random small inputs

Top traps to avoid

Submitting after passing only the sample.
Debugging by changing code at random.
One-letter names for everything.

Mastery check

0 of 15 answered

Answer from understanding, not memory of the page. You need 12 of 15. Each answer is explained, and you can retry as often as you like.

1.A solution passes the sample but fails hidden tests. What is the best first step?
2.A list has 5 items. Which range visits every index exactly once?
3.You have a clever O(n) solution you are not fully sure about. What is a good way to build confidence?
4.Why is "\n".join(results) followed by one print better than printing inside a loop for 10⁵ lines?
5.count_below_buggy([1, 2, 3], 10) returns 2 instead of 3. What is the cause?
6.What does an assert do when its condition is False?
7.Why write small functions?
8.When a program gives a wrong answer, what is the best first step?
9.Which testing habit suits contest problems?
10.After def f(x=[]): appends 1 to x and returns it, what does the second call f() return?
11.What is the main risk of a bare except: in a contest solution?
12.Why test n = 0 and n = 1 even though they are small?
13.def f(a, b=None): if b is None: b = []; b.append(a); return b. What does print(f(1), f(2)) print?
14.For many lines of input in Python, why is sys.stdin.read() often preferred to repeated input()?
15.What does print(7 if 0 else 8) print?

Best Coding Practices

After this lesson you will be able to

Builds on

Unlocks

A pilot's checklist

Habits that save the most time

Off-by-one: the most common bug

The edge-case checklist, applied

Reading input and writing output

Reading the code

Tests you can run in one second

Reading the code

Finding a bug on the smallest failing input

Reading the code

Stress testing: trust, but verify against brute force

Reading the code

Practical costs of these habits

Edge cases about the process itself

Mistakes to avoid

How to know it is time to use these habits

Spot the off-by-one

Stress test a clever solution

Wrap-up

Remember this

Cheat sheet

Top traps to avoid

Mastery check