開発規約
ディレクトリ構成
開発時のディレクトリ構成は以下のようにしてください。 archive ディレクトリには、testAndTar.sh を実行時に作成される tar/gz ファイルが格納されます。 ums ディレクトリは、本ページを構成する forrest ドキュメントを格納します。
isas/archive
isas/umsCodeGenerator/yyyymmddvv
isas/ums
開発言語
C 言語
大雑把に言うと、C 言語の方言を使ってはなりませぬ。 ISO C 1999 に従うべきです。 その全ての機能を使ってよいわけではなく、 拡張された機能の使用は極力避けるべきです。 ISO C 1999 の機能のうち明示的に用いていて良いのは以下の機能です。
- 各種ビット長の整数型
- 可変長配列を持つ構造体 (TBD)
より具体的には gcc -fstd=c99 -Wall にて処理できる ソースをコンパイルすることが要求条件です。 また、int_least16_t と int16_t の違いを意識してください。 単発の関数呼び出しのパラメータの場合は前者で、 巨大な配列をメモリに確保する場合は後者を用いるべきです。
Java
以下で動作すること。
- Java2 1.4
- Java5
2005051901：Java、C、XSL についてのコーディング規約
設計メモ：不要な UMS__ ums__ 接尾辞の削除 (例外名称, 制御条件)
設計メモ：C・Java 命名規約
設計メモ：オブジェクト指向
文字コード
ファイルの文字コードは以下に従ってください。
| ファイル | 文字コード | 改行コード | 備考 |
|---|---|---|---|
| .c .h .java .sh | EUC-JP | LF | vi でも emacs でも日本語表示が可能なため。 |
| .xml .xsl | UTF-8 | LF | XMLプロセッサはすべて、UTF-8 と UTF-16 をサポートすることが保障されているため。 |
２次的な関連情報
開発方針
- 改修は一度にまとめて実施せず、可能な限り細かい単位で行ってください。
- ソースコードの改修を行う際は、まず設計メモを作成してください。
- なるべく説明の文書は軽く、ソースコード自身が説明になるようなものを作成してください。
リビジョン管理
変更を行った際は以下の情報を、変更を行ったファイルの先頭と $TABLETOOLS_HOME/changes.xml に記述してください。
- バージョン(yyyymmddvv)
- 変更者
- 変更内容
変更を行った際は、$TABLETOOLS_HOME/tool/testAll.sh を実行し、デグレがないことを確認してください。 なお、試験パターンが全て通ると、isas/archive ディレクトリに umsCodeGenerator-yyyymmddvv.tar.gz が作成されます。
ソースコードの管理は、Subversion で行っています。
設計メモ：変更履歴のつけ方
文書管理
改修を行った時点で、この forrest ドキュメントの関連する部分を改版してください。
forrest ドキュメントの管理もソースコードと同様、Subversion で行っています。
不具合管理
リリースノートの書き方
Releases ページに載せるリリースノートには、 以下の内容を記述してください。
- 仕様・性能・インターフェースなど、ユーザビリティに関わる情報。
- ヘルプ情報など、ユーザにとって必要な情報。
- ユーザに必要な bugfix の情報(Bugzilla 番号、Bug の概要)。
2006年06月23日 以降のリリースノートは、 pod を使用して作成しています。 pod を使用してリリースノートを作成する際は、pod 形式の yyyymmddvv_ums_release.pod ファイルを作成し、 pod2html が使用可能な環境で以下のコマンドを実行してください。
$ pod2html --css=ums.css --title="yyyymmddvv umsCodeGenerator release" < yyyymmddvv_ums_release.pod > yyyymmddvv_ums_release.html