Django (anti)patterns ‹ Django antipatterns Fork me on GitHub
Django (anti)patterns

Antipatterns

  1. A GET request with side-effects
  2. A model with a …Model suffix
  3. Chaining querysets together
  4. Checking ownership through the UserPassesTestMixin
  5. Constructing a new form when validation fails
  6. Fetching the logged in user with a query
  7. Filtering in the template
  8. Foreign key with _id suffix
  9. Giving related_name=… the same name as the relation
  10. Manually constructing a slug
  11. (Over)use of .values()
  12. Plural model class names
  13. Refer to the User model directly
  14. Rendering content after a successful POST request
  15. Return a JsonResponse with safe=False
  16. Signals
  17. Use datetime.now as default=… for a created_on field
  18. Use .get(…) to retrieve the object in a view
  19. Using a FloatField for money
  20. Using commit=False when altering the instance in a ModelForm
  21. Using len(…) on a QuerySet with no further use
  22. Using request.POST or None

Patterns

  1. Annotate a condition as BooleanField
  2. Set values to a created/updated object in a class-based view

Troubleshooting

  1. Can not extract/filter a Date(Time)Field when time zones are enabled