We should also decide on a format for file/module header comments. I  
would like to suggest:

FileName.py : a description of what the code in this file does

This software is licensed as described in the file COPYING, which
you should have received as part of this distribution.  The terms
are also available at http://projectsycamore.org/license.
If newer versions of this license are posted there, you may use a
newer version instead, at your option.

This software consists of voluntary contributions made by many
individuals.  For exact contribution history, see http:// 


This is borrowed from the Subversion who have done a great job of  
building a development support system (We should probably borrow a  
few more things from them).

Would it be wise to keep a revision log in the individual files as well?


On May 20, 2007, at 9:22 PM, [EMAIL PROTECTED] wrote:

I've started a doc about coding conventions[1] used in Sycamore. I've
noticed a lot of annoying inconsistencies and I'd like to start fixing
things. Once we all decide on the best practices I'll clean up the code.
Please look at the doc and let me know what you think. This will involve
database changes so it will require an SQL patch that I'll produce. I
don't have that much experience with postgres so I might need some  
help on
that side.

I've produced a simple Entity Relationship Diagram for Sycamore[2] to  
import the contents at this website[3]. I didn't add the views yet.  
there are no relations in my diagram because that's exactly how things
exist after buildDB.py is run. Adding foreign keys with cascading
updates,deletes *may* reduce some complexity in the code (but I haven't
looked). The DB does also need some normalization. I imagine we can
eliminated a few tables to do exactly the same functions.

[1] http://www.projectsycamore.org/Coding_Standards
[3] http://ondras.praha12.net/sql/demo

Sycamore-Dev mailing list

Sycamore-Dev mailing list

Reply via email to