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.

A non-unique primary key allows the same value to be used for multiple records thus multiple results could be returned for Model.objects.get(pk=1).

The TEMPLATE setting is a list of the template engines used when finding template files and rendering them.

The DIRS key within the TEMPLATE list denotes the directories where the engine should look for template source files.

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

The TEMPLATE setting is a list of the template engines used when finding template files and rendering them.

The DIRS key within the TEMPLATE list denotes the directories where the engine should look for template source files.

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.

Django version is not receiving bug fixes, and security fixes, and data-loss fixes.

New version of Django is available, including bug fixes and new features.

Your website is vulnerable to a number of common hacker attacks because MIDDLEWARE setting is missing django.middleware.security.SecurityMiddleware.

Your website is vulnerable to clickjack attack because the MIDDLEWARE setting is missing django.middleware.clickjacking.XFrameOptionsMiddleware - so users can be tricked into interacting with your website without realising.

Your website is vulnerable to CSRF attacks because the MIDDLEWARE setting is missing CsrfViewMiddleware - so a hacker can fool your website into thinking a request is coming from a logged in user.

Your website is vulnerable because the CSRF_COOKIE_SECURE setting is not set - so hackers have an easier time stealing your CSRF cookies on HTTP connections, allowing them to circumvent your CSRF protection.

Your website is vulnerable to Man In The Middle attacks because the SECURE_HSTS_SECONDS setting is missing - so a hacker can intercept and change requests performed over HTTP.

Your website is vulnerable to Man In The Middle attacks on subdomains because the SECURE_HSTS_INCLUDE_SUBDOMAINS setting is missing - so a hacker can intercept and change requests performed over HTTP.

Your website must set SECURE_HSTS_PRELOAD in order to be submitted to Chrome's list of sites that are hardcoded as being HTTPS only.

Your website is vulnerable to being tricked into executing uploaded malcious code because the SECURE_CONTENT_TYPE_NOSNIFF setting is not set.

Your website is vulnerable because the SECURE_SSL_REDIRECT setting is not set - so a hacker can read, intercept, and change requests performed over HTTP.

Your website is vulnerable because the SESSION_COOKIE_SECURE setting is not set - so hackers have an easier time stealing your users' session cookies on HTTP connections.

Your website is vulnerable because the SESSION_COOKIE_HTTPONLY setting is not set - so hackers have an easier time stealing your users' session cookies using an XSS attack.

len(queryset) performs the count at application level. That is much less efficient than doing queryset.count(), which does the calculation at database level and just returns the count.

When working with foreign keys, accessing the related field will result in a database read. That can be eliminated by using *_id, which is the foreign key value that Django has already cached on the object to make this scenario more efficient.

Comparing queryset.count() is less efficient than checking queryset.exists(), so use querySet.count() if you only want the count, and use queryset.exists() if you only want to find out if at least one result exists.

This can load every row in the database table into memory because the queryset is evaluated. Checking if a queryset is truthy/falsey is much less efficient than checking queryset.exists().