Clean Code, Git & Professional Workflow — Python Course

What you'll learn

The last step from "writes Python" to "professional developer" isn't a new feature — it's habits: writing code others can read, letting tools enforce quality, and collaborating with Git so a team can build together safely.

By the end of this lesson you'll be able to:

Write Pythonic, readable code that follows PEP 8
Apply the DRY, KISS, and YAGNI principles (and know when not to)
Automate quality with black, ruff, and mypy
Use Git branches, commits, and pull requests
Run checks automatically in CI and follow security basics

Pythonic, readable code

Code is read far more often than it's written. PEP 8 is Python's style guide (4-space indents, snake_case names, clear spacing), and "Pythonic" means using the language's idioms rather than translating from another language.

pythonic.py

# Unpythonic: index-based loop, manual list building
result = []
for i in range(len(names)):
    if names[i] != "":
        result.append(names[i].upper())

# Pythonic: iterate directly, use truthiness, use a comprehension
result = [name.upper() for name in names if name]

Tip

Favor clear names over comments, small functions that do one thing, and direct iteration over index juggling. If a line makes a reader pause, a well-named variable or helper usually beats a clever one-liner.

DRY, KISS & YAGNI

DRY — Don't Repeat Yourself: fold duplicated logic into one function or constant.
KISS — Keep It Simple: the simplest solution that works is usually the right one.
YAGNI — You Aren't Gonna Need It: don't build for imagined future requirements.

Watch out

These are guidelines, not laws. Chasing DRY too hard produces tangled abstractions that are harder to change than a little duplication. Some repetition is fine until the pattern is clear — premature abstraction is its own bug.

Format, lint & type-check

Don't argue about style — automate it. black formats code the same way every time, ruff catches bugs and style issues in milliseconds, and mypy checks your type hints. Run them locally and in CI.

terminal

$ pip install ruff black mypy
$ black .          # auto-format to a consistent style
$ ruff check .     # fast linter: unused imports, bugs, style
$ mypy src         # static type checking

Git & pull requests

Git tracks every change and lets a team work in parallel. The everyday flow: branch, make small focused commits with clear messages, push, and open a pull request for review before merging.

terminal

$ git checkout -b feature/greeting   # work on a branch
$ git add -A
$ git commit -m "Add greeting command"
$ git push -u origin feature/greeting
# then open a Pull Request so a teammate can review it

Note

Write commit messages in the imperative mood — "Add greeting command," not "added stuff." A commit should be one logical change with a message that explains why. Your future self reading git log will thank you.

CI/CD & security

Continuous Integration runs your checks automatically on every push and pull request, so broken code never reaches the main branch. Here's a GitHub Actions workflow that lints, type-checks, and tests:

.github/workflows/ci.yml

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -e ".[dev]"
      - run: ruff check .
      - run: mypy src
      - run: pytest

Key idea

Security is part of the workflow, not an afterthought: never commit secrets (use environment variables and .gitignore), pin and update dependencies, review what third-party packages you pull in, and let CI fail the build when a check doesn't pass. Small, consistent habits prevent most incidents.

Recap & quick check

Key takeaways

Write for readers: follow PEP 8, use Pythonic idioms (direct iteration, comprehensions, truthiness).
DRY, KISS, YAGNI are guidelines — but avoid premature abstraction; a little duplication can beat a tangled one.
Automate quality: black (format), ruff (lint), mypy (types) — locally and in CI.
Git workflow: branch -> small focused commits (imperative messages) -> push -> pull request for review.
CI runs checks on every push/PR so broken code never reaches main.
Security basics: keep secrets out of git, pin/update/review dependencies, and fail the build on failing checks.

Quick check

1. What is PEP 8?

2. What does YAGNI advise?

3. Which tool automatically formats your code to a consistent style?

4. What is a pull request for?

5. What does Continuous Integration (CI) do?

You've reached the professional toolkit. All that's left is to prove it — by building. Next up: Module 41 — Capstone Projects.