ORM queries are more readable and relationships more explicit when related_name is specified.

It's better to use apps.get_model, which guarantees the Model's fields will reflect the fields in the database even if models.py is vastly out of step with the database.

It's good to, as a minimum, specify noop in RunPython so the migration can be skipped when going backwards, and even better to specify a function that undoes the migration.

Hard-coding static asset urls is brittle because the place the files are stored depends on the `STATICFILES_STORAGE` used - so if in prod the storage backend uploads to S3 or even renames the file then this hard-coded URL will break.

Using "{% static ... %}" solves that as it knows exactly where the files are stored.

The order of middleware affections the outcome. Some middleware are dependant on the functionality of other middleware. For example a middleware that requires usage of request.session should come after the SessionMiddleware.

URL names must be unique otherwise reverse('url_name') and {% url 'url_name' %} will link to the "wrong" page half of the time.

Using reverse(...) is better than using reverse_lazy(...) when the url is being reversed after URLConf has been loaded.

Incorrectly ordered middleware can stop the middleware working as intended.

Incorrectly ordered middleware can stop the middleware working as intended.

Hard-coding urls makes changing URLs harder, and makes linking to the wrong page easier - so harms maintainability.

unique_for_date/month/year is very brittle and over time will likely be a source for unexpected behaviour.

Using from django.conf import settings simplifies the code and makes it more maintainable.

Using TextField for very long string fields would simplify the code and make is easier to maintain.

NullBooleanField is deprecated and will be removed a future version of Django.

Stating defaults add complexity when reading the code but does not change Django's behaviour.

Stating defaults add complexity when reading the code but does not change Django's behaviour.

If null is True and blank is False then validation becomes more complex.

Primary key must be unique by definition: it's a field that uniquely identifies the record.

DIRS must be absolute paths. Relative paths will not work.

DIRS must be forward slashes, even in Windows. Forward slashes do not need escaping, and they are cross Operating System compatible.

ORM queries and Python code are made more complex because values will sometimes be None and other times str.

ORM queries are more readable and relationships more explicit when related_name is specified.

The Django coding style suggests a standard order of model attributes. Increasing standardisation and predictability of your code style helps other developers read your code.

Predictable project structure and following common patterns simplifies maintenance of a codebase.

Django developers come to expect Admin-related objects to be in admin.py. Failure to do this will result in more time spent looking for where code lives.

A taller Model with many fields may be more difficult to maintain than a shorter Model with fewer fields.

Taller models.py with many Models may be more difficult to maintain than shorter models.py with fewer Models.

Taller models.py with many Models may be more difficult to maintain than shorter models.py with fewer Models.

DIRS must be absolute paths. Relative paths will not work.

Your code is harder to test in isolation because the value of settings.DEBUG affects other Django behaviours including error handling. Consider using a feature flag instead.