Grahame et al.
Internally we maintain a distinction between the LexGrid project and the CTS projects (LexGrid being the Browser, and CTS being the server.) Dan is doing some work cleaning up and separating the implementation of CTS from the interface, and I am doing some HL7 work on the LexGrid Editor. Would it make sense to house CTS and LexGrid as follows?
-cts
-- cts
-- LexGrid
-----Original Message-----
From: ohf-dev-bounces@xxxxxxxxxxx [mailto:ohf-dev-bounces@xxxxxxxxxxx] On Behalf Of Grahame Grieve
Sent: Tuesday, March 28, 2006 1:23 AM
To: Open Healthcare Framework Mailing list
Subject: [ohf-dev] Coding Standards
hi
While I was visiting IBM last week, we discussed a number of topics related to coding standards, and I advance them here for consideration.
These are open for discussion; once we have consensus I will move this onto the wiki. None of these are intended to supercede other eclipse & java coding standards; they all apply, and if any of this is in conflict with them, we'll have to change this.
Packages/namespaces:
We will have a utility package org.eclipse.ohf.utilities.
It will contain a few things, general utilities of use to
everyone. Where possible, we will use things from the
Apache Commons rather than putting things in the utlities
package (and I have to go through the current code there
taking things out that duplicate Apache commons stuff).
All our other packages start with the namespace
org.eclipse.ohf.[component]
current components:
- cts
- h3et
- hl7v2
- wado
- ihe
within IHE, there is the following pattern:
org.eclipse.ohf.ihe.[profile].[actor]
The package org.eclipse.ohf.ihe.[profile].[actor].core
should be the run-time implementation of the actor.
in addition, there is org.eclipse.ohf.ihe.common.
for things shared between different ihe profiles.
As yet we haven't considered namespacing within the
common area.
Committers should discuss on this list if they want to use something
outside this pattern.
There's something missing from this namespacing, names for the framework
stuff. When we start getting framework code, then we'll discuss this one.
What to commit to cvs, how to layout packages
Any files used in development should be put in the cvs. Non code, things
like schemas, should be put in the directory \Resources\[function]\[format]
within the project root. \src should contain the actual source (this is
an eclipse standard). JUnit tests should be in the package project in a
directory \src_tests
JUnit
Ideally, core packages should be agressively JUnit tested. There is less
need to JUnit test UI packages, but even they may contain functionality that
is useful to JUnit test.
Outstanding issue: Many of our JUnit tests will refer to example messages,
and other resources. How do we set this up?
Package Extensions.
Core packages do not yet need to extend anything; though this requirement
may be introduced later once we have a framework.
Java Version
There is 2 important targets where Java 1.5 is not supported: Embedded
systems and enterprise production application servers. Core packages
should generally use java 1.4 features only. UI packages are free to
use Java 5 features.
This is not a hard rule; we have agreed that the H3ET core package(s)
will use Java 5. But where it's not overly taxing, core packages should
use Java 1.4.
Exceptions
There is a base exception OHFException in the utility package. Where
possible & reasonable, OHF exceptions should extend this base exception.
Discussion please (and not just from committers, there is a number of other
folks on this list who will be contributing code through the committers.
While the committers will be expected to enforce these coding conventions,
all contributers have to conform...)
Grahame
_______________________________________________
ohf-dev mailing list
ohf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ohf-dev