1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
There are a few rules required when working on Keryx code.
1) First and foremost, use proper python docstrings.
def x_intercept(m, b):
"""
Short description
"""
actual code goes here
Read this article for more details:
http://epydoc.sourceforge.net/manual-docstring.html
2) Use 4 space tabs. We don't want our code looking different for everyone that
attempts to read it do we?
3) Make all code changes in private bzr branches and then propose for merging
into the main branch. This keeps updates separate and the main branch stable
while we review merge proposals and accept them only after verifying they work.
4) Function names start with lower case word and consecutive words are
capitalized, for example createProject()
5) Function variables are all lower case and separated by under scores, ie:
plugin_name
6) Class names use are capitalized for every word, ie: class InputError()
7) Global or library level variables should be in ALL CAPS
Each database will contain the following tables: (Subject to change)
Meta Table
==========
Contains file version (in case we make changes to this format later)
Version of Keryx created by
Project plugin name
* Values dictated by the plugin
Package Table
=============
Columns dictated by plugin
|