Repositories

For internal projects, use out Gitlab-server: https://gitlab.geo.uni-bonn.de:4443/users/sign_in

Python requirements

  • We use Python 3.X for development.

Virtualenvs/Virtualenv-wrapper

Introduce yourself to virtualenv-wrapper, learn the basic handling.

Git requirements

Understand, and use, the following git commands:

  • git clone
  • git pull / git push
  • git add
  • git commit
  • git branch
  • git checkout
  • git merge

Software Development using Python

  • Put scripts to generate the data into the GIT rep.
  • git-annex can be used to manage large data files in git-repositories:
  • Use Python 3.4 or newer
  • The program ‘pep8’ checks .py files for pep8-errors (apt-get install pep8)
  • Use 4 spaces instead of TAB (can be set in most editors, otherwise: use another editor)
  • maximum 79 characters per line
  • Each executable script should start with “!#/usr/bin/python”
  • make executable with “chmod +x SCRIPT.py”
  • execute with ./SCRIPT.py
  • Bookmark the documentations for the following packages (local version can often be found in /usr/share/doc/python-XXX)
  • Decide on the project language in the beginning and stick to it!
  • English is the preferred language to comment and document your software
  • Create working examples for your software in a ‘examples/’ subdirectory.
  • These examples are directed to new users who want to learn how to use the software in general or how to use specific features.
  • Create working test cases for your software in a ‘tests/’ subdirectory.
  • Create a documentation subdirectory ‘docs’ right at the beginning
  • Document all functions
  • Documentating early and extensive has multiple advantages
  • Re-use text for publications/thesis
  • Structure the development phase
  • A central place to store notes and todos
  • sections to include in your documentation:
  • Installation
  • Quick start guide
  • Usage
  • Implemented formulas
  • TODO-List
  • Literature (include links to PDF files if available), put PDF files in a directoy ‘literature’
  • Design-sketches (flow-charts)
  • Code (can be automatically included by sphinx)
  • A ‘docs’ subdirectory could have the following subdirectories:
  • literature/ <- put PDF files in here
  • doc/ <- put sphinxs documentation in here
  • <- add new subdirectories for all notes and additional documentation
  • Create only small functions (~1 screen page long) with only one purpose
  • NEVER ever start your variables with “my”!
  • Plan your program on paper before you start to write code
  • Use pseudocode
  • Flow-charts really help to understand the problem