Django Code Smells

Using Django Getting Started
1

Hi everyone!
I’m currently working on an academic project focused on identifying specific code smells in Django development and would greatly appreciate insights from this community. Could fellow Django developers share their experiences regarding the most common code smells they encounter while working with Django? Any examples or patterns you’ve noticed would be incredibly valuable for my research. Thank you in advance for your contributions!

2
  1. Any use of django.core.signals is suspect
  2. Not taking advantage of model forms
  3. Not taking advantage of forms
  4. CBV death (first the dev learns about CBVs/generic views, then dev goes crazy and turns everything into CBVs, then everyone dies - and that’s the smell)
  5. Disorganized url organization/scheme, (hard to define a rule, but you definitely know it when you see it)
  6. settings.py file disorganization
  7. secrets in settings.py
  8. Not taking advantage of management commands
  9. Not taking advantage of migration features
  10. Template dirs/files disorganization
3

I agree with all the above, and would like to add -

  1. Over-reliance on the admin. (The code smell is all the code added to a ModelAdmin class to make it do things it was never intended to do.)
  2. Custom template tags that try to convert DTL into something like JSP.
  3. Poor model design. (This covers a variety of smells including using the wrong data type, non-normalized, or improperly de-normalized models.)
  4. User-written code that replicates a system (Django or Python) function.
  5. Obvious security vulnerabilities. (SQL injection and unvalidated input from the browser being the two most common I see.)
  6. Not taking advantage of third-party packages where appropriate.
4

Can you explain in some more detail what you mean by #4? While I agree that not every view has to be a CBV, I found CBVs a huge relief in the projects that I have worked on…

5

I don’t know about the original author’s intent on #4, but I’ll share my thoughts on it.

I have nothing against CBVs themselves. My opinion is that it’s not the idea of a CBV that is the problem. It’s the mindset that the Generic CBVs provided by Django are the only CBVs available, and everything you do must fit into one of them.

Like everything else, you can create problems for yourself by using features for purposes for which they are not intended.

In this case, one of the problems with the Django-provided Generic editing CBVs is that they’re designed to work with a single model.

If you’ve got a page containing forms for two or more models, that’s a bad fit for those CBVs. You can find a couple of examples here containing discussions where people are trying to handle two related models on one page, and trying to make that “fit” within a standard UpdateView. In my opinion, it doesn’t work well.

There are also cases where a truly trivial view can be much better served as an FBV.

See Django Views — The Right Way for a lot more on this topic. (I’m not the author, but I easily agree with the majority of the opinions he expresses.)

6

Ah I see. I agree, trying to make that fit is not a good idea.

Thank you for the link! That’s exactly the sort of texts that I’m looking for, discussions about the pros and cons of certain patterns and best practices. If you know more blogs, websites or books like that (not only regarding views, but any Django patterns or concepts), I would be very much interested.

7

The problem with identifying references like this is that they can become out-of-date.

I do recommend GitHub - wsvincent/awesome-django: A curated list of awesome things related to Django as a “source of sources”. It’s a curated list that is currently well-managed.