Общие рекомендации к коду проекта

Используем black style
Длина строки — 119 символов;
Для сортировки импортов используем пакет isort, следим чтобы не было неиспользуемых;
Отступы — 4 пробела;
Консистентность: одинаковые кавычки, одинаковые методы решения одинаковых проблем;
Комментарии к функциям оформлены в виде Docstrings в соответствии с Docstring Conventions: начинаются с большой буквы, заканчиваются точкой и содержат описание того, что делает функция;
Логические блоки кода выделены пустыми строками;
Используется Guard Block;
Следим, чтобы в репозиторий не попадали системные и временные файлы (pycache, .vscode, и т.д.);
Где возможно используем кортежи вместо списков (обзор различий)

Вместо такого:

filters = ["test"]

Делаем так:

filters = ("test",)

Так плохо:

def ugly_one(self):
    return "{smth} - {here}".format({"smth": self.smth, "here": self.here})

Так хорошо:

def nice_one(self):
    return f"{self.smth} - {self.here}"

Так плохо:

f"some_result: {UsingSomeClass.and_ofcourse_method('with', a, self.bunch, of, USEFUL_PARAMS)}"

Так хорошо:

# делаем полезное и понятное
some_result = ...
f"some_result: {some_result}"

Переменные названы в соответствии с их смыслом, по-английски, нет однобуквенных названий и транслита;
Используем Type Hints;

В urls.py в конце роутов стоит слеш /;
Для URL применяются соответствующие path converters;
Для всех ссылок используется reverse();
Отсутствие закомментированного кода и стандартных комментариев Django (# Create your views here. и другие);
Отсутствие любых пустых файлов *.py в модулях Django (urls.py, views.py и других);
Соблюдается официальный код-стайл Django (Если он не противоречит PEP8, настройкам линтеров и форматеров кода);

Все ключевые участки кода покрыты тестами: каждый ответ каждого эндпоинта API и важная бизнес-логика;
У тестов есть понятное описание, что именно проверяется внутри. Используйте pep257.

Provide feedback