The 4 Clean Code Principles in Django
Clean (your) code in Django
This article is written for the purposes of an individual review for CSUI’s Software Engineering Project Course 2022.
Introduction
Cleaning is probably not your favorite pastime activity, and it’s certainly not mine. Whether it’s cleaning your room or cleaning your code, it’s probably not going to be a good time. But both of them have something in common. It’s very important.
Contents
1. Some of Clean Code’s Principles
As you may have known already, clean code is not about computers or compilers, it’s about humans. For computers, how you write your code doesn’t matter one bit as long as it’s syntax is right and it’s logically right. But humans are not computers. Your fellow co-workers and other programmers may not necessarily be able to read your code, especially if you didn’t write clean code.
Some of the most well known Clean Code principles are:
- KISS (Keep It Simple (and) Stupid)
- DRY (Don’t Repeat Yourself)
- YAGNI (You Aren’t Gonna Need It)
In the following parts, I’ll try to show examples of these principles in Django.
2. KISS in Django
KISS (Keep It Simple (and) Stupid) is basically telling you to keep your code short, simple, and easy to read by others.
Use Django Forms, Serializers, Permissions, and Decorators Rather Than Manual Alternatives
When learning Django, you’ve probably learned Django forms, serializers, and many other things, as I did a long time ago.
But sometimes, I find myself questioning the benefit of using these things. Couldn’t you just write a few lines of HTML codes for forms? Or write more lines of code in the views instead of making serializers or permissions?
Yes, you can do just that to do the same thing. But because you can do it, doesn’t mean you SHOULD do it.
First thing is, manual HTML Forms is not safe! By using Django forms, your forms will be safer because it uses a CSRF Token as Cross-Site Request Forgery protection. You can search this on your own, but from clean code’s perspective, it’s also not good for manual HTML forms. Look at the comparison here:
Without Django Forms:
With Django Forms:
You may think, “wait a minute, isn’t the code with Django forms longer?”. Yes, it’s longer if you include the forms.py file. But if you compare only the views.py file, you’ll see that the one with Django forms will be much simpler and easy to read than without Django forms. This is because even when the code (combined) is longer on the first snippet, it’s separated neatly. This means that you can infer what is supposed to do more easily.
This is the essence of KISS principle. You need to make the code simple and easy to read for others, even if you end up writing more code or have to think about it more. The most important thing to take away from this is make simple and readable code for others.
Use Class-Based Views Rather Than Function-Based Views
Use Class-Based Views instead of Function-Based Views when necessary. This is because even though Function-Based views is more flexible than its counterpart, Class-Based Views will be more readable on long and redundant functions/views.
I won’t go far in explaining this as most people probably have known about Class Based Views, but you can check out my other story about refactoring in Django here. One of the sections there goes a little bit further on Class-Based Views in Django REST Framework.
3. DRY in Django
DRY or Don’t Repeat Yourself is a principle that explains itself. You shouldn’t repeat yourself in your code. Some things that you can do in Django to reduce redundancies are:
Use Decorators for Restricting Access to Views
If you haven’t used decorators before, you’ve probably written this in your views before:
if request.user.is_authenticated:And if you have multiple views in one file, it might look just like this:
Well, what if I tell you there’s a better way that doesn’t involve copy-pasting and repeating yourself over and over again? Here’s how with decorators:
Wow! Cool right? You can also see that in the decorator, you could write any custom code you want. So it’s not only for restricting access to views or redirecting you somewhere. You can save things to user’s session like referer URL paths before they go to the view or many other things you can imagine. The sky is the limit!
Put Frequently Used Codes to Separate Helper Functions and in a Separate File
This is another one where it’s really easy to implement for all of us! Extract frequently used code to a separate helper function and put it in utils.py file.
Example of sending emails without helper functions:
Example of sending emails with helper functions:
The difference is quite stark, to be honest and it would be much more needed for more complicated and complex functions.
4. YAGNI in Django
YAGNI or You Aren’t Gonna Need It is a principle that tells us to not get ahead of ourselves. Sometimes I and maybe some of you would write code for the ‘future’. Maybe we’ll need this or that later on, so might as well write it now right? Nope! It’s really a bad habit for clean code because most often than not, you aren’t gonna need that code.
For example, I’ll go back to the decorators that we’ve discussed before. Maybe after learning that we can make @login_required decorators, we would like to make another one for users who are qualified.
Well, we’ve not really implemented this qualified thing, but maybe we’ll write it now for the ‘future’.
Well….. it’s done.
2 years later…
“What’s this ‘qualified’ decorator thing?”
Yes, you’ve probably forgotten about it and never used it. That’s because you probably didn’t need it in the first place. So, the takeaway from this is you should not add functionality or any other code until it is deemed necessary unless you want a bloated and messy codebase for your projects.
