Contribution guidelines

Conding style:

• Python:

  • The classic and well know pep8, with the exception of the limit of characters per line (89 accepted)

• Django:

  • The rules stated in here https://docs.djangoproject.com/en/1.7/internals/contributing/writing-code/coding-style/

• Javascript (for web interafaces):

  • Your code have to be valid for http://www.jshint.com/ with the configuration stored in the repo here at iepy/webui/.jshintrc

Names:

Within this project we are dealing with several data types, sometimes similar between them, sometimes A the abstraction of B, which is an abstraction of C. You must be very careful with using exact names for manipulating them. Examples:

• If you have a sequence of EntityOcurrences, don't name it "entities", because there's another model named Entity.

Good Coder Citizen:

• Do not leave "fixme" of "todo" notes. Raise the discussions somewhere else than the code. The tracker, a mailing list, a conference, but not in the code.
• Do not leave on main branches commented code. If it's dead code, remove it, we have git for reviewing it if we want.
• Do not comment or skip tests. If a test is failing, is while better to have explicit evidence of that.

Testing:

• run the entire suite before pushing, you fool
  • if you find things failing caused by your changes, fix it.
  • if you have things failing and you are not sure what caused that, or how to fix it, create a ticket, or discuss with the team.
• each time you add or change functionality, please invest the time for:
  • if you defined new data types, write Factories for them (http://factoryboy.readthedocs.org/en/latest/)
  • write at least a couple of tests that walk thru the basis
  • if you are adding some dependence to some heavy package, please test that, but:
    • DON'T test what the other tool does. Test what we do with the other tool.
    • Mock the actual call to that external tool