The following conventions are used throughout this site.

File and folder names

Generally, they are denoted in bold and italics as in _this_is_a_file_name_. Sometimes, though, you may find them formatted as inline code, for clarity purposes (as in this_is_a_file_name_too). The context will help you figure out when one is used over the other.

Inline code

inline code is used for, well, code, as well as file and folder names, variables, command line commands, and command line outputs. Again, the context will help you figure out what is what.

Blocks of code

Blocks of code are presented as follows:

import os
from manage import get_env_variable
DJANGO_SECRET_KEY = get_env_variable('DJANGO_SECRET_KEY')
BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
SECRET_KEY = DJANGO_SECRET_KEY

When a code listing is too extensive, I use ... to signify lines of code that are not relevant to the point I'm making and that I omit for brevity and clarity. Example:

...
WSGI_APPLICATION = 'config.wsgi.application'
...     
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
    }
}

LANGUAGE_CODE = 'en-us'
TIME_ZONE = 'UTC'
USE_I18N = True
USE_L10N = True
USE_TZ = True

STATIC_URL = '/static/'
...

What's up with the bold words that randomly appear within blocks of code?

highlight.js, the engine that powers code highlighting on this website, sometimes thinks that the blocks of code in question are related to programming language X, and highlights some of the words accordingly. Annoying it is, I know. Please drop me a line if you know of a fail-proof highlighting engine out there!

Files and folders ignored on folder / file trees

Unless necessary, I omit the following files and or folders when listing file structures:

  • Git
  • DS_Store (Mac OS)
  • Python compilation files
  • System generated comments

Additionally, when listing directories and files, I use (...) to signify that files and or folders exist in that location but are omitted for brevity. Example:

|____djangoboilerplate
| |____apps
| | |____config
| | | |____(...)
| | |____main
| | | |____(...)
| | |____manage.py
| | |____media
| | | |____twitter48.png
| | |____static
| | | |____css
| | | | |____global.css
| | | |____img
| | | | |____twitter48.png
| | | |____js
| | | | |____global.js
| |____docs
| | |____readme.md
| |____requirements
| | |____(...)

Suggested package or software versions

You may find instances where you are asked to install a specific version of a piece of software (e.g., pip install django-livereload-server==0.2.3). The intent is that, if you are following along, like in a tutorial-like style, you get the results that I get as I am writing the article. It's advisable that you stick to the suggested version. After the tutorial is complete, you can try to update to a later version of the software, and troubleshoot it from there if you run into trouble.


Happy coding!!!