Contributing¶
Thank you for considering contributing to Nadzoring! This page covers the development workflow, code style rules, and submission process.
Setting Up the Development Environment¶
git clone https://github.com/alexeev-prog/nadzoring.git
cd nadzoring
pip install -e ".[dev]"
Code Style¶
Nadzoring uses ruff for linting and formatting. Run the full check before committing:
ruff check src/
ruff format src/
Key conventions enforced by the ruff config:
Double quotes for strings
Google-style docstrings (
Drules) with examples where relevantisort import ordering (
Irules)PEP 8 naming:
snake_casefor functions/variables,PascalCasefor classes,UPPER_CASEfor module-level constantsNo
print()in library code — use thenadzoring.loggermodule
Design Principles¶
Before adding a feature, read Architecture. The short version:
SRP — one module, one concern.
DRY — extract repeated patterns into helpers or the
utils/package.KISS — prefer simple, readable code over clever one-liners.
Error handling — never raise on expected network/DNS failures; return structured error data instead.
Type hints — all public functions must have complete type annotations; use
TypedDictfor structured return values.
Writing Tests¶
Tests live in tests/. Run them with:
pytest tests/
New features require at least:
A happy-path test
An error/edge-case test (e.g. domain not found, timeout)
Submitting a Pull Request¶
Fork the repository.
Create a feature branch:
git checkout -b feat/my-feature.Make your changes and add tests.
Run
ruff checkandpytest— both must pass.Update the relevant
.rstdocumentation file.Open a PR with a clear description of what changed and why.
Reporting Issues¶
Open an issue on GitHub at https://github.com/alexeev-prog/nadzoring/issues. Please include:
Nadzoring version (
pip show nadzoring)Python version and OS
The full command or code snippet that triggered the issue
The full error output