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
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.
in Django,
almost all the variables' naming style is UPPER_CASE_WITH_UNDERSCORES,
for instance:
INSTALLED_APPS = [
]
MIDDLEWARE_CLASSES = [
]
and so on...
what's the conventions it follows?
In addition to being constants and following PEP8, these constants are Django settings. Settings are defined in a settings module, and Django exposes an object, django.conf.settings, that proxies attributes in this module. The proxy object only exposes settings that are all uppercase.
So if you want your settings to be available on django.conf.settings, using uppercase variable names is not just a convention, it's required.
Pep8, its common across most python and PyCharm helps to enforce it.
In particular, this is the rule for constants
Constants are usually defined on a module level and written in all capital letters with underscores separating words. Examples include MAX_OVERFLOW and TOTAL.
It follows PEP 8.
The letters are upper case because they are constants. And the underscore is a usual python naming convention.
UPPER_CASE_WITH_UNDERSCORES
Django setting required uppercase letter for custom-defined settings variables
These are certain rules in Django for creating our own settings
Creating your own settings
There’s nothing stopping you from creating your own settings, for your own Django apps, but follow these guidelines:
Setting names must be all uppercase.
Don’t reinvent an already-existing setting.
For settings that are sequences, Django itself uses lists, but this is only a convention.
Please have a look at Django documentation - https://docs.djangoproject.com/en/3.0/topics/settings/
Django itself follows that rules and Naming convention in python like splits with the underscores are from pep8.
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.
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.
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.