Skip to content
This repository has been archived by the owner on Jan 11, 2019. It is now read-only.
Stefan Foulis edited this page Sep 19, 2013 · 12 revisions

this is not the real thing, just scraps of topics that should go into the real thing.

Project Development

  • create feature branches for your work. It's ok to push feature branches to the main repo. But you can also make a fork to your own repo if you want.
  • create a pull request as early as possible, even if you're not done yet. add a prefix to the title: "[WIP] my new feature". [W]ork [i]n [P]rogress: meaning don't merge yet!. This allows a nice overview of who is working on what and where merge conflicts might arise.

Deployment branches

At the beginning of the project there is just the 'develop' branch. It can be deployed to "dev" and "live" servers. After the first release, "master" shold be used for "live" and "develop" for "dev". Using the git-flow-ish branch management.

Naming conventions

  • created_at, created_on, modified_at, modified_on (past time form!)
  • item_count (for amounts)

python: use single quotes everywhere.

templates:

  • always use tabs in html
  • all django templatetags: use single quotes '
  • all html tags: use double quotes
  • all JS: use double quotes
  • template readability counts: it does not matter if the resulting html has excess whitespace after indenting ifs

Database Fields

  • ForeignKeys that can be blank, should also have on_delete=models.SET_NULL. This prevents cascade deletes of a lot of attached content that is usually not what you want.
  • Filer fields are also ForeignKeys, so the rule above applies!
Clone this wiki locally