BEST PRACTICES FOR
Some tips, tricks and common practices
Hi! I'm Juan David Hernández
Core Concepts
Keep It Simple, Stupid
(KISS)
“Simplicity is the ultimate sophistication”
~ Leonardo Da vinci
Fat Models, Utility Modules, Thin Views, Stupid Templates
Put more logic into anything but views and templates
Start With Django by Default
Examine all possibilities offered by the framework before using alternatives
Be Familiar with Django's Design Philosophies
It’s a way of doing things designed to help us put together maintainable projects in a reasonable amount of time.
Coding Style
The Importance of Making Your Code Readable
code written in a clear, consistent style
- Avoid abbreviating variable names
- Document your classes and methods
- Comment your code
- Refactor repeated lines of code into reusable methods
- Keep functions and methods short
PEP 8
PEP 8 coding conventions: http://www.python.org/dev/peps/pep-0008/
-
“Use 4 spaces per indentation level.”
-
“Separate top-level function and class definitions with two blank lines.”
-
“Method definitions inside a class are separated by a single blank line.”
The 79-Character Limit
On open source projects
The 99-Character Limit
On private projects
The Imports
PEP 8 suggests that imports should be grouped in the following order:
Standard library imports
Related third-party imports
Local application or library specific imports
The Imports
The import order in a Django project is :
- Standard library imports
- Imports from core Django
- Imports from third-party apps including those unrelated to Django
- Imports from the apps that you created as part of your Django project
Example
Use Explicit Relative Imports
Bad Example
use "From __future__ import absolute_import "
Avoid Using Import *
Django Coding Style
The Optimal Django Environment Setup
Use the Same Database Engine Everywhere
Here are some of the issues encountered:
-
You Can’t Examine an Exact Copy of Production Data Locally
-
Different Databases Have Different Field Types/Constraints
-
Fixtures Are Not a Magic Solution
Use Pip and Virtualenv
They are the de facto standard for Django projects
PIP
Tool to install python packages
Virtualenv
Tool for creating isolated Python environments for maintaining package dependencies
How to Lay Out Django Projects
Default Project Layout
Three-tiered approach
Top Level: Repository Root
README.rst
docs/
.gitignore
requirements.txt
Second Level: Project Root
Project Django
Directory
Directories
.py
Third Level: Configuration Root
settings.py
url.py
Sample Project Layout
What About the Virtualenv?
Fundamentals of Django App Design
The Golden Rule of Django App Design
“The art of creating and maintaining a good Django app is that it should follow the truncated Unix philosophy according to Douglas McIlroy: ‘Write programs that do one thing and do it well.”
~ James Bennett
In essence, each app should be tightly focused on its task
What to Name Your Django Apps
When possible keep to single word names
A good, obvious app name makes the project easier to maintain.
As a general rule, the app’s name should be a plural version of the app’s main model
When in Doubt, Keep Apps Small
The apps layout is an art, not a science
Try to keep as small as possible apps
It’s better to have many small apps than to have a few giant apps.
What Modules Belong in an app
Settings and Requirements Files
Some best practices to follow:
- All settings files need to be version-controlled
- Don’t Repeat Yourself
- Keep secret keys safe
Using Multiple Settings Files
A Development Settings Example
Separate Configuration From Code
Use environment variables
To see how you access environment variables from the Python side
To access environment variables from one of your settings
Using Multiple Requirements Files
It’s good practice for each settings file to have its own corresponding requirements file
Example
base.txt
local.txt
$ pip install -r requeriments/local.txt
Preguntas?
No muy corchadoras.....