Django: The Right Way(Or something like it)

Coding like most tasks is defined by habits.Habits mostly derived from our experiences while learning a language, a technology or being taught . Habits we mostly tend to be loyal to till we discover a better way or a much more acceptable ‘habit’ of writing ‘habitual’ codes for our ‘habitual’ projects.

My name is Lekan Wahab and I am a Django Programmer(Or at least that’s what I tell myself.)

I recently went through a realization that the way i’ve been doing django for a while which might not be necessarily wrong, isn’t completely right or fool-proof either. This article is a short description of the

‘Before Realization’ habits I used to work with and ‘After Realization’ habits I’d most likely be working with.

The Old Me::

It all starts with the compulsory django-admin startproject oldme and django-admin startapp oldmeapp. While both of these

haven’t portrayed me as a wrong yet, here a couple of things i used to do that do:

1. Not thoroughly understanding my project:

I don’t know if this is a feature of all newbie programmers but i very much used to love to just code than actually understanding what i’m working on.

2. Project Directories:

I had an habit of using the default django directory setup. While this in itself is not bad, i’ve come to understand that it is always best to set up folder structures based on project requirements.

3. Using virtualenv with out virtualenvwrapper :

Normally you can create and use Python programs without that, but using virtualenv can help a lot.

Such virtual environment provides many possibilities such as:

● On production servers it allows to run applications created for different Python versions.

● On testing servers it allows to perform many tests including:

○ Testing the installer script if that really installs all necessary libraries with checking their versions.

○ Testing applications using different set of libraries.

○ Checking if upgrade of a library won’t cause errors.

The Discovery:

I was recently given a code to go through at work . While i was not required to edit the code, this gave me ample opportunity to really understand the code and learn a whole bunch of things from it. The things i learnt from this project are what have been compiled now and named “The Right Way of Doing Django.”, or at least the new habit i would be following.

Below are some of the things i learnt:

On Models:

1.It is a good practice to separate the different properties of the model into relations, attributes, manager and functions. Especially if other programmers will have to deal with the code.

2.Use verbose_name to define the name that will be displayed. Otherwise, Django by default uses the object name replacing underscores with spaces.

3.Use help_text to define the help text that will be shown in forms. It should be a description of what you expect the user to write/insert in this field.

4.Use the ugettext_lazy function to indicate what will be translated. Note that at the beginning, we import that function with the short name _, so that we don’t have to type it every time we need it. I use it in every verbose_name and help_text, which are the pieces of code in this file that will be displayed to the user. Later on, I will explain where do you actually translate these words/sentences.

5.Use a custom object manager if you want to define complex queries of that object. For example, you might want to find, several times in your code, the first 5 next tasks the user has to do. You can define this query in your custom manager and use it anywhere in your code more easily.

6.Always validate your models with python manage.py validate before making migrations and migrating.

7. Make sure you have DRY at the back of your mind always.

On URLS:

1. URLs in a Django app should not be coupled to the underlying Python code. Tying URLs to Python function names is a Bad And Ugly Thing.

2. Make URLs as flexible as possible.

3. Your project URLconf should simply include URLconfs from your applications whenever possible. This keeps your application logic inside your application and your project simply serves as a pointer to it.