Topic: coding-practice
-
Refactoring in small, verified steps
Refactoring changes structure without changing behaviour; doing it in tiny steps with tests green between steps, and separating refactoring commits from behaviour changes, keeps it safe and reviewable.
-
Working practices for an AI agent changing a codebase
Read before writing, reproduce before fixing, change in small verified steps, run the project's own checks, never retry writes blindly, and report exactly what was tested; a methodology for agents that edit code.
-
Technical debt as a metaphor and as a decision
Technical debt describes the future cost of a shortcut; the metaphor is useful when the debt is deliberate and tracked, and misleading when it excuses careless work or is used to describe every imperfection.
-
Docstrings that tools and readers can use
PEP 257 defines where docstrings go and how they are formatted; a consistent style (Google or NumPy) with a one-line summary, argument and return descriptions and raised exceptions makes them usable by readers, editors and documentation generators.
-
Automated formatting and linting as a team contract
Delegating layout to a formatter and mechanical checks to a linter removes style debates from review; EditorConfig, PEP 8 and tools such as Ruff show how the contract can be encoded in the repository.
-
Preventing SQL injection with parameterised queries
Never build SQL by concatenating untrusted strings; pass values as parameters so the driver sends them separately from the statement, and allow-list any identifiers that must be dynamic.
-
The test-driven development loop
Write a failing test, make it pass with the simplest change, then refactor with the tests green; the loop keeps design decisions small and gives every line a reason to exist.
-
Code-Review: eine Checkliste für Reviewer
Eine kompakte Prüfliste für Code-Reviews: Zweck verstehen, Design vor Stil, Korrektheit und Randfälle, Tests, Lesbarkeit; Rückmeldung innerhalb eines Arbeitstags und Freigabe, sobald die Änderung den Code insgesamt verbessert.
-
Systematische Fehlersuche in sechs Schritten
Fehler reproduzieren, präzise beobachten, eine Hypothese mit Vorhersage bilden, ein Experiment pro Änderung, ausgeschlossene Ursachen festhalten, Ursache beheben und mit einem Regressionstest absichern.
-
What a README must answer
A README answers, in order: what the project is, who it is for, how to run it, how to test it, how to contribute, and where the deeper documentation lives; everything else belongs elsewhere.
-
Test doubles: stubs, mocks, fakes and when to use which
Test doubles replace a collaborator in a test; stubs return canned answers, fakes are working lightweight implementations, spies record calls and mocks verify expected interactions. Mocking everything couples tests to implementation.
-
Conducting a code review that improves the code
A reviewer's procedure derived from Google's engineering practices: judge whether the change improves overall code health, review design before style, and keep turnaround within a business day.
-
Turning a bug report into a regression test
Before fixing a bug, reproduce it as a failing automated test that names the report; the test proves the fix and prevents the bug from returning.
-
Feature toggles: types, lifetime and clean-up
Toggles decouple deployment from release, but each toggle is a branch in the code; classify them by purpose (release, experiment, ops, permission), give each an owner and a removal date.
-
The test pyramid and where each test belongs
The test pyramid recommends many fast unit tests, fewer integration tests and very few end-to-end tests; the shape follows from speed, isolation and diagnostic value, not from dogma.
-
Writing a minimal reproducible example
A minimal reproducible example contains the least code, data and environment that still shows the problem; producing one is often half of the diagnosis and is what maintainers and other agents need to help.
-
Gradual typing in Python with type hints
Type hints (PEP 484) are optional annotations checked by external tools such as mypy; adding them incrementally to a codebase catches interface mistakes and documents intent without changing runtime behaviour.
-
Structuring a unit test: arrange, act, assert
Each unit test sets up one scenario, performs one action and checks one observable outcome; naming the scenario in the test name and keeping fixtures explicit makes failures self-explanatory.
-
Choosing a configuration format: JSON, YAML or TOML
JSON is strict and universal but has no comments; YAML is readable but has surprising implicit typing; TOML is explicit and comment-friendly for flat-to-moderate structures. Pick by who edits the file and what parses it.
-
Handling Unicode text correctly
Decode bytes to text at the boundary, encode back only on output, normalise when comparing, and remember that a user-perceived character can be several code points; Python's Unicode HOWTO and Unicode TR15 cover the mechanics.
Machine-readable: JSON