I'm going through our code quite randomly at the moment while investigating the multi-currency changes.
What stands out at me is that we have:
* different indenting methods (tabs vs spaces)
* different intenting styles (2, 3, 4+ spaces)
* different widths: 80 on most files, but I've seen anything above too
* single vs double underscores as separators in tokens
I'm sorry, but it's starting to disturb me (quite a bit). So, here's my proposal:
* We remove all tabs from the code base in one huge commit (except for Makefile)
* From there on, we watch out not to add new tabs to the code base (add a test case?)
* We choose a single intenting style
- and create .emacs and vimrc examples for peolpe to use with our project; publish those on ledgersmb.org
* We settle on either 80 or 132 character-width per file and reformat all files which are over the chosen maximum;
--> With emacs starting up at 80 characters width, I'm all for 80 characters (that way multiple windows fit next to each other on my screen)
* We settle on a standard for using double underscores. My proposal:
- In Perl, we always use a single underscore, as modules are enforced through OO
- in PostgreSQL/pgPLSQL, we use the format <module>__<module-local-identifier>; making the payments code look like payment__list_all_open_invoices() or payment__post().
(Currently the former exists, but the latter is called payment_post?!)
* Each indenting level takes 2 spaces (to be added to the .emacs and vimrc examples as well)
* SQL keywords in UPPERCASE
* non-sql keywords in lowercase
* COMMENTS whereever in the code base as normal sentences: One capital and then lowercase until the dot.
* Comments are not essays: "Let's ...." and "We ..." are to be avoided;
Example from the payments code: "We want to set a gl_description"
Should be written as: "Set the gl_description"
* Further formatting choices and minimum (function) documentation requirements to be established as we go and to be collected on ledgersmb.org
* Various project-root level files are to point to the ledgersmb.org
URL where these docs can be found
Robust and Flexible. No vendor lock-in.