Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/WorkTeam01/team-practice/llms.txt

Use this file to discover all available pages before exploring further.

All code in this project follows Python standard conventions — PEP 8 for style, PEP 257 for docstrings, and every new function must be covered by pytest tests before the PR can be approved. Reviewers check these standards explicitly and will request changes for any code that does not meet them.

​
Python style (PEP 8)

The project follows PEP 8 — the official Python style guide. The most important rules to keep in mind while contributing are:
  • 4-space indentation — never tabs.
  • Maximum line length of 79 characters — break long expressions across multiple lines using parentheses.
  • snake_case for functions and variables — e.g. abs_value, first_number, current_value.
  • Meaningful names — dividend and divisor are better than a and b when the role is clear; single-letter names are acceptable only in mathematical contexts (e.g. add(a, b)).

​
Docstrings (PEP 257)

Every public function must have a docstring. The project uses the Google-style docstring format with Args, Returns, Raises, and Examples sections. Below is the exact format used in calculator.py: 
def add(a: float, b: float) -> float:
    """Suma dos números.
    
    Args:
        a: Primer número
        b: Segundo número
        
    Returns:
        La suma de a y b
        
    Examples:
        >>> add(2, 3)
        5
        >>> add(-1, 1)
        0
    """
    return a + b
Include an Examples section with at least two cases — one typical and one edge case (negative number, zero, boundary value). If the function can raise an exception, add a Raises section as well.

​
Type annotations

All function signatures use Python type hints. Annotate every parameter and the return value. Use built-in types (float, str, bool) rather than importing from typing for simple signatures. 
def divide(a: float, b: float) -> float:
Type hints serve as inline documentation and allow static analysis tools to catch type errors before tests run.

​
Testing requirements

The project ships with 63+ test cases across two test modules. Every contribution must maintain or extend that coverage.
  • Every new function added to src/calculator.py needs corresponding tests in tests/test_calculator.py.
  • Every new GUI behaviour added to src/gui.py needs corresponding tests in tests/test_gui.py.
  • GUI tests must use the tkinter mocks provided in tests/conftest.py so that they run in headless CI environments without a display.
The standard test structure for a calculator function looks like this: 
def test_add():
    """Test suma básica."""
    assert add(2, 3) == 5
    assert add(-1, 1) == 0
    assert add(0, 5) == 5
    assert add(-2, -3) == -5


def test_divide_by_zero():
    """Test que división por cero lanza excepción."""
    with pytest.raises(ZeroDivisionError):
        divide(10, 0)
Run the full suite before pushing: 
pytest -v
Or target a specific module: 
pytest tests/test_calculator.py -v
pytest tests/test_gui.py -v

​
Code review checklist

CI status
Does the PR pass all CI tests in the GitHub Actions pipeline? A failing pipeline blocks merge regardless of approval.
Docstrings
Are all new public functions documented with a proper PEP 257 docstring including Args, Returns, and Examples sections?
Test coverage
Do new features or bug fixes have corresponding tests? Edge cases (zero, negatives, invalid input) should be explicitly covered.
PEP 8 compliance
Does the code follow PEP 8 style? Check indentation, line length, naming conventions, and blank-line usage.
Conventional Commits
Is every commit message in the <type>: <short description> format? See the Commit Conventions page.
Correct PR target
Does the PR target dev and not main? PRs targeting main will be redirected.
Force-pushing to a branch with an open PR is not allowed. It rewrites history, breaks review threads, and makes it impossible to see what changed between review rounds. Push new commits on top of the existing branch instead.
The canonical reference for all contribution guidelines is CONTRIBUTING.md in the repository. If anything in these docs conflicts with that file, the CONTRIBUTING.md file takes precedence.

Build docs developers (and LLMs) love

Get started for freeTalk to us