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