emrevarol.com

Lecture Materials

Best Coding Practices and Effective Code Review

A2SV - University of Rwanda

View Presentation

A2SV Code Review Checklist

The gold standard. Ten categories to evaluate every pull request you review.

1 Clarity and Readability
Ask
  • Are function and variable names clear?
  • Can I understand the code without guessing?
  • Is the intent obvious?
  • Is the logic easy to follow?
Red Flags
Names like x, tmp, data, calc, process; deeply nested logic; large unclear functions
2 Function and Design Quality
Ask
  • Does each function do one clear thing?
  • Is business logic separated from side effects?
  • Is the design easy to test?
  • Is any function doing too much?
Red Flags
Validation + saving + email + logging in one function; printing inside logic functions; hardcoded behavior spread across the file
3 Correctness
Ask
  • Does the code actually solve the problem correctly?
  • Are assumptions explicit?
  • Are all cases handled?
Red Flags
Missing input validation; dictionary key assumptions; magic values; silent failure
4 Edge Cases
Ask
  • What happens with empty input?
  • What happens with invalid input?
  • What happens with missing keys?
  • What happens with zero or negative values?
Red Flags
Only happy path considered; no defensive checks where needed
5 Tests
Ask
  • Are tests included?
  • Do tests check exact outcomes?
  • Are edge cases covered?
  • Would these tests catch regressions?
Red Flags
Only one test; weak assertions like > 0; no invalid input cases; no tests for changed logic
6 Duplication
Ask
  • Is logic repeated?
  • Can shared logic be extracted?
  • Are business rules duplicated in multiple places?
Red Flags
Repeated formulas; repeated condition blocks; repeated hardcoded values
7 Error Handling
Ask
  • Are errors handled clearly?
  • Does the code fail in an understandable way?
  • Are invalid states visible?
Red Flags
Returning None without explanation; swallowed exceptions; hidden failure modes
8 Maintainability
Ask
  • Will this be easy to extend later?
  • Will another engineer be able to modify this safely?
  • Does this make the codebase cleaner or messier?
Red Flags
Hardcoded rules; overly large PR; tightly coupled logic
9 Repository Quality
Ask
  • Is the repo structure clear?
  • Is the README useful?
  • Can a new engineer run the project easily?
  • Are dependencies visible?
Red Flags
No setup instructions; weak README; confusing layout; missing tests directory
10 PR Quality
Ask
  • Is the PR focused?
  • Is the title descriptive?
  • Is the description helpful?
  • Is the change size reasonable?
Red Flags
Vague titles; no explanation; mixed unrelated changes; giant PRs

Review Comment Templates

Professional phrasing for common review scenarios. Use these as starting points.

Naming
"Could we rename this function to better reflect its purpose?"
"This variable name feels too generic. Can we make it more descriptive?"
Logic
"Could we simplify this condition to improve readability?"
"Would it make sense to extract this logic into a helper function?"
Tests
"Can we add a test for the empty input case?"
"Could we assert the exact expected value here instead of using a broad check?"
Structure
"This function seems to be doing multiple things. Can we separate responsibilities?"
"Would splitting this into smaller functions make it easier to test and review?"
Edge Cases
"What happens if this key is missing?"
"Should we validate the input before processing it?"
PR Quality
"Could you add a short PR description explaining the change and how it should be tested?"

Live Demo: Review This Pull Request

A deliberately flawed PR for practice. Can you spot the problems?

Branch: feature/cart-total-update
Title: "Update cart calculation logic"
Description: "Updated the cart calculation logic and added support for discount."
src/cart.py
def calc(items, user, d=False): t = 0 for i in items: if i["type"] == "book": t += i["price"] * 0.9 else: t += i["price"] if d: t = t - t * 0.1 if user is not None: if "is_premium" in user: if user["is_premium"] == True: t = t - t * 0.05 return t def process_cart(items, user): total = calc(items, user, True) print("cart processed") return total
tests/test_cart.py
from src.cart import calc def test_calc(): items = [{"type": "book", "price": 100}] user = {"is_premium": True} assert calc(items, user, True) > 0
README.md
# Cart Project cart logic
Review Guide - Problems to Find
PR-Level Problems
  • Vague PR title: "Update cart calculation logic" does not describe what changed
  • Description is generic and unhelpful
  • No test plan or instructions for reviewers
Code-Level Problems
  • Function name calc is too generic - should be calculate_cart_total
  • Parameter d is unclear - should be discount_enabled
  • Variables t and i are not descriptive
  • Magic numbers: 0.9, 0.1, 0.05 should be named constants
  • Deeply nested if blocks for premium check - use .get()
  • process_cart has a side effect (print) mixed with business logic
  • No input validation for items or user
  • Boolean parameter d=False passed positionally as True is confusing
Test-Level Problems
  • Only one test case for the entire module
  • Weak assertion: > 0 does not verify correctness
  • No edge case tests (empty list, missing keys, non-premium user)
  • Does not test process_cart
Repo-Level Problems
  • README is essentially empty - no setup instructions, no description
  • No information on how to run tests
Improved Version - cart_improved.py
src/cart_improved.py
BOOK_DISCOUNT_RATE = 0.10 GENERAL_DISCOUNT_RATE = 0.10 PREMIUM_DISCOUNT_RATE = 0.05 def calculate_item_price(item): item_type = item["type"] price = item["price"] if item_type == "book": return price * (1 - BOOK_DISCOUNT_RATE) return price def apply_general_discount(total_price, discount_enabled): if not discount_enabled: return total_price return total_price * (1 - GENERAL_DISCOUNT_RATE) def apply_premium_discount(total_price, user): if not user or not user.get("is_premium", False): return total_price return total_price * (1 - PREMIUM_DISCOUNT_RATE) def calculate_cart_total(items, user, discount_enabled=False): total_price = 0 for item in items: total_price += calculate_item_price(item) total_price = apply_general_discount(total_price, discount_enabled) total_price = apply_premium_discount(total_price, user) return total_price def process_cart(items, user): total_price = calculate_cart_total(items, user, discount_enabled=True) return total_price

Homework Assignment

PR Review Assignment: Review Like a Professional Engineer

Your submission must include:

  • 10 total Review comments minimum
  • 3 min Naming-related comments
  • 2 min Testing-related comments
  • 2 min Design or function responsibility comments
  • 1 min Repository quality comment
  • 1 min Refactoring suggestion

Submission Format

File: src/orders.py
Line/Area: calc function
Comment: The function name is too generic. Could we rename
it to calculate_order_total for clarity?

File: tests/test_orders.py
Line/Area: test_calc
Comment: This test only checks that the result is greater
than zero. Could we assert the exact expected value instead?

Review the following files:

src/orders.py
def calc(items, vip=False): total = 0 for i in items: if i["type"] == "book": total += i["price"] * 0.9 elif i["type"] == "electronics": total += i["price"] else: total += i["price"] if vip == True: total = total - total * 0.05 return total def checkout(items, user): total = calc(items, user["vip"]) print("checking out order...") print("total is", total) return {"ok": True, "total": total}
src/utils.py
def f(x): if x == None: return False return True
tests/test_orders.py
from src.orders import calc def test_calc(): items = [{"type": "book", "price": 100}] assert calc(items, False) > 0
README.md
# Orders Run it with python.
Great engineers do not just make code work. They make code understandable, testable, reviewable, and trustworthy.
Quote of the Day
"The code you are too busy to clean today becomes the problem that owns your team tomorrow."