Is there an existing naming convention for using abbreviations in Django classes (e.g. models, forms, etc)? Specifically I'm interested if there's different rules between abbreviations/acronyms/initialisms?
So far I've only found examples of non-acronyms:
XMLField
HTTPRequest
What should a JSON field be called (since it's an acronym)?
JSONField, or
JsonField
From PEP 8:
Use JSONField over JsonField.
Since CapWords are used for class names, this comment applies:
Note: When using abbreviations in CapWords, capitalize all the letters
of the abbreviation. Thus HTTPServerError is better than
HttpServerError.
Related
I have subtly different entities that are important enough with respect to the relationships, flexibility, and expression of my schema that they warrant separate models.
How should I name/ case these?
a) Layerinput, Layerhidden, Layeroutput
b) Layer_Input, Layer_Hidden, Layer_Output
c) LayerInput, LayerHidden, LayerOutput
Right now I am leaning option a so that Django doesn't do anything too automagically incorrect with them, but that won't look great in documentation and code. Will use them with either DRF or graphql.
If you're referring to naming Classes, you should choose c) as shown in image below (obtained from https://docs.djangoproject.com/en/2.1/topics/db/models/#verbose-field-names).
If you're referring to the field_names (eg. name and age under the class CommonInfo in the figure above), then the convention for django is as followed:
According to PEP8 conventions,
Class names should normally use the CapWords convention.
These naming conventions are also followed in the Django framework. So you can choose the third option.
Use camelCase (option c), this helps you differentiate words in a variable while minimising the characters (as in option b)
Use this as a guide: https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/
CamelCase (option c) is also useful because Django will know how to render your model names in the admin site. For example 'LayerInput' will appear correctly as 'Layer input' without you having to specify it anywhere.
I'm trying to setup a LinkColumn and I've seen in the examples that a the args parameter has usually the form args=[A('pk')]. I'm wondering what is the meaning of the A().
From the documentation of django-tables, A is the Accessor Class.
A string describing a path from one object to another via attribute/index accesses. For convenience, the class has an alias A to allow for more concise code.
Relations are separated by a . character.
So basically you are using the primary key in this example to access the objects.
From django-tables2 source code
class Accessor(str):
'''
A string describing a path from one object to another via attribute/index
accesses. For convenience, the class has an alias `.A` to allow for more concise code.
Relations are separated by a ``.`` character.
'''
Symfony uses a set of coding standards to set out for us how to program and what style we should use. My question is short and simple. I would like to know if symfony (together with doctrine ORM) has a similiar set of standards when it comes to building and structuring my database.
For example:
Should I use Camel Case?
Should my table name be user or users
Do I use capitals?
What charset is recommanded?
Basically, you do not need to care about database naming as Doctrine will do everything for you.
You should use Doctrine cli commands to generate your database schema based on your entities, or even better use Doctrine Migrations to maintain changes.
Should I use Camel Case?
For entity class names, I'd recommend sticking with PSR, so yes, use CamelCase.
Symfony by default uses underscore naming strategy, so entity CamelCase will be generated as table camel_case (if not manually overriden).
You can set another naming strategy, but the default underscore strategy is a fine choice.
Should my table name be user or users
user is a ANSI SQL reserved word, so I recommend using users. Or, if you prefer having entities in singular, try person instead.
Do I use capitals?
Again, Doctrine naming strategy will solve this for you. Moreover, eg postresql converts all table names and such identifiers to lowercase, so using capitals explicitly can cause problems.
What charset is recommanded?
Use UTF-8 (or more specifically utf8mb4 if needed). There are few reasons to use any other.
What is the best naming convention for instance, url and template names of Django models with more than one word?
Instances
yetanothermodel = YetAnotherModel()
yet_another_model = YetAnotherModel()
Url names
'yetanothermodel_detail'
'yet_another_model_detail'
Template names
'yetanothermodel_detail.html'
'yet_another_model_detail.html'
It is your personal choice. But if you are working in a team I would say you should be applying the Python PEP8 standard of coding; that way all members of the team are using the same process and naming conventions to write their code.
In this instance:
yet_another_model = YetAnotherModel()
Variables names should be lower-case, underscore separated. With class names using the camel casing naming convention.
and
'yet_another_model_detail'
Url names should be treat like a variable name or function name, lower-case separated with _ (underscores).
Templates:
Whilst there is no defined naming convention for templates I treat the naming the same as a function name. So in these cases I go for lower-case with underscore word separation.
I also keep the templates inside of the django apps (sometimes, I will have a templates directory which will have a directory for each app name).
I also stick the CRUD type at the end of the filename.
For example:
<app_div>/user_profile.html
<app_dir>/user_profile_update.html
<app_dir>/user_profile_view.html
<app_dir>/user_profile_delete.html
Background: I'm creating kind of simplified pseudo-ORM for use in Django. Classes obviously use CamelCase convention, while Django app is underscored lowercase. Which leaves me with a few options:
Django ORM style: app_name_someclass
proper underscore style: app_name_some_class
as-is: app_name.SomeClass
possibly some other using different separators etc.
Are there any well established naming conventions for DynamoDB?
So far, from what I've seen in examples, it seems that it's free-for-all.
Following the examples in the AWS documentation here and here would lead to the following conventions:
Table names in Upper Camel Case, e.g. MyTable.
Attribute names also in Upper Camel Case, e.g. Id, ProductCategory etc.
Actually the examples are a bit inconsistent when it comes to acronym capitalization - with ISBN and Id in the first link and both CustomerID and CustomerId in the second link. Either style could be argued but I'd personally lean towards only capitalizing the first letter in an acronym. See here for more debate on this subject.
It's free for all. I name tables as "users", "secret-files", "seen-blog-posts", and their attributes as "user.name", "date.recent.iso", etc.