HACKING

Axioms of Style

1. When in doubt, follow the style of the existing function or file.
1.1. When creating a new file, follow the style of existing files, pe. Game.h/.cpp.
1.1.1. Do not forget to include the license header.
2. Code indentation is done with single tabulators.
3. Try to avoid creating very long lines. There is no set maximum.
4. Sort includes by type (project, system) and alphabetically.


Where to start
If you don't know what to work on, check out the FIXMEs
and TODOs spread throughout the code, the more detailed todo on our wiki at
http://gemrb.org/wiki/doku.php?id=todo or ask either on the forums or IRC.
Alternatively, just start playing one of the games and see what annoys you, 
then start fixing it.

Useful tools
- gdb
  You can use the following to automatically run gemrb and already start with a
  breakpoint in abort():
    gdb -q -iex "set breakpoint pending on" -iex "b abort" -ex run --args path/to/gemrb -c agame.cfg
  (also available as a script in admin/run.gdb)
- valgrind
  We bundle a suppression file for upstream problems at testing/python.supp
  You can use it for example this way (if running from the build dir):
    valgrind --track-origins=yes --suppressions=../testing/python.supp \
      gemrb/gemrb -c agame.cfg &> valgrind.log
  (also available as a script in admin/run.valgrind)
- diff display for IE binary formats
  Check out admin/enable-ie-git-diff if you want git log and others to be able
  to display diffs of included binary files (spells and other overrides).