3

I wrote a model in this format in Django:

class Block(models.Model):
    block_id = models.AutoField(primary_key=True)
    block_name = models.CharField(max_length=200)
    block_code = models.CharField(max_length=200)
    block_content = models.CharField(max_length=200)
    block_change_date = models.DateTimeField(auto_now=True, default=datetime.now())
    block_published_date = models.DateTimeField(auto_now_add=True, default=datetime.now())

Is this a useful practise to have block_ (or whatever other model name) for each or does it just add length to the field names?

1 Answer 1

8

No, it's not.

Think about it, where would you ever need them?

  • Not when you create the model: you know what model are you creating.

  • Not inside the model itself: you know where you are too.

  • Nor when accessing the model later: you still know the type of the model, unless you don't care about the type, in which case prefixes will be only an annoyance.

Imagine a model such as:

class Person(models.Model):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)

Would person.person_first_name make more sense than person.first_name? Would Person ever contain a first_name which is not the first name of the person, so that you'll end up for example with:

class Person(models.Model):
    person_first_name = models.CharField(max_length=30)
    person_last_name = models.CharField(max_length=30)
    persons_husband_first_name = models.CharField(max_length=30)
    persons_first_child_first_name = models.CharField(max_length=30)
    persons_pet_first_name = models.CharField(max_length=30)
    administrator_first_name = models.CharField(max_length=30)

You might have already seen such code, but code like this is indicative of a complete misunderstanding of OOP by the author.

Another aspect to consider is inheritance. You may have:

class Person(models.Model):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)

class Employee(Person):
    pass

class Freelancer(Person):
    pass

Following the convention where model members are prefixed with the class name, you'll end up expecting employee.employee_first_name, but finding employee.person_first_name, which is counter-intuitive. If you start overriding members, things become even messier.

Finally, if you need a more authoritative source, more specific to Django models, look at documentation. The example above is copied from it. You'll see that other examples don't have such prefixes either.

2
  • I thought it might improve readability but you are indeed correct, it does get confusing. Commented Apr 4, 2015 at 15:55
  • It will be even more annoying if you have to access the database directly using sql, as Django already adds the app names to tables. Commented Apr 18, 2015 at 16:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.