« 「シンプル・イズ・ベスト」はややこしい | トップページ | 告知:「受注生産」のためのシステム開発ライブ »

2014.06.27

フィールドIDが全角日本語であることの意義

 テーブルIDやフィールドIDの命名基準については、昔からさまざまに語られてきた。ローマ字表記で"HINMOKU"とすべきか、英単語の省略形も駆使して"HINMST"とすべきか、記号や番号を組み合わせた無意味なコードとすべきかなどと議論されてきた。現在の私は、テーブルIDについては"AT010"のようにサブシステム区分付の番号方式で、フィールドIDについては"QTTORIHIKI"のようにデータタイプとローマ字(たまに英単語の省略形)を組み合わせるという基準に従っている。

 それが今では「全角日本語をそのままIDにすればいいではないか」と言われ始めている。"品目マスター"とか"標準売価"といった全角文字をそのままIDとして使うのである。古参の技術者にはギョッとさせられるような提案なのだが、UTFが普及している現在ではそれほど突飛なアイデアではなくなっている。じっさい効果があるようで、技術者仲間のひとりは「一度やると戻れなくなりますよ」と証言している。

 効果があることは明らかとはいえ、すべてのIDをいきなり全角日本語にしてしまうのは難しいだろう。既存の開発標準もあるし、頭の固い技術者の抵抗にも会いそうだ。なによりも、全角日本語のフィールドIDを許すDBMSを使えたとしても、それを許す処理系を使い続けられるとは限らない。

 XEAD Driverの次リリースで搭載される「記述モード切替」は、ここらへんにスマートに対処するための機構である(2014/07/02公開済)。各テーブル定義毎に、それを一次テーブルとして操作する機能定義の中で実行されるJavaScript(テーブル・スクリプト)を組み込めるのだが、編集するための「IDモード」からボタン操作で表示専用の「名称モード」に切り替えできる。つまり、フィールドIDを半角英数字にしたまま、スクリプト上では視認性の高い全角日本語のフィールド名で読めるのである。

<IDモード>
JT020_AMTORIHIKI.value = JT020_QTTORIHIKI.value * JT020_PRTORIHIKI.value;

 ↓↑ Ctrl+N

<名称モード>
JT020_取引金額.value = JT020_取引数量.value * JT020_取引単価.value;

 この効果は私にとってとくに喜ばしい。「XEAD Driverは<書いた仕様書がそのまま動作する>ための開発基盤である」と謳っているからだ。通常の機能定義は名実ともに「実行可能な仕様書」なのだが、上記のテーブル・スクリプトについては仕様書と言い切れない思いがあった。フィールドIDが半角文字列で書かれていたからだ。これを全角日本語名で示せるのであれば、より仕様書に近い定義要素として位置付けできる。

 蛇足ながら、それらのスクリプトで記述される内容がビジネスルール系に終始していて、クラス定義のような専門的な表現が出てこない点を強調しておきたい。それらのスクリプトは、システムの保守担当者にとって「ビジネスルール説明書」としてそれなりに理解できるものでなければならない。クラスだのインタフェースだのといった枠組みは、彼らには難解だし余計である。個別の開発案件においてオブジェクト指向の枠組みは意図的に隠蔽されなければいけない。オブジェクト指向は、オブジェクト指向を隠蔽してくれる開発基盤(DSP, Domain Specific Platform)を開発するためにこそ活用しよう。

|

« 「シンプル・イズ・ベスト」はややこしい | トップページ | 告知:「受注生産」のためのシステム開発ライブ »

コメント

日本語をプログラミング言語や RDBMS のシンボルとして使う場合、命名規則が複雑になるのですよね。英数字記号は全角半角どちらにするのか、漢字はどの規格・水準のものまでが許可されるのか、といったことが思い浮かびます。外字は当然NGとして、UNICODE にも規格・水準があり製品とそのバージョンによってサポートされる範囲はまちまちです。この辺をきちんとしておかないと、メンテナンスや移行時に問題が起きることが予想されます。

レビューして、人の目でチェックする、というのも現実的ではないですので、何かしらプログラムを用意して、プログラムでチェックすべきですね。コンパイラの一部として動作しないと、抜けがでてきそうですが。

昔、日本語名を使っているシステムの改修案件で、全角括弧で開いて半角括弧で閉じてる(あるいはその逆)など、全角半角が混在していて、大変な思いをしたことがあります。半角英数字しか使わない、というのも、それはそれで割り切った合理的考えと思います。

投稿: IG | 2014.06.28 10:20

IGさん

言われるとおりだと思います。予想しにくい副作用を避けるために、半角英数字のほうが無難ではあるのでしょうね。

いっぽうで、半角英数字を使うゆえの支援も必要だと考えます。従来の仕様書には、開発者が半角文字ばかりのコードを読み書きするために必要な「日本語の(つまり漢字混じりの)処理要件説明書」の意味あいがあったと思います。全角日本語の定義名を含むリポジトリと統合された開発環境があれば、そんな余計な資料を作らずに済む。プログラミングの問題を解決するためのプログラミング上の工夫の余地はまだまだありますね。

投稿: わたなべ | 2014.06.28 18:32

私は、1990年に独立した時から、テーブルID、フィールドID、メソッド名は、全角日本語可のRDB、4th Dimensionを使っています。Mac出身ですが、2000年ごろからWindowsと併用です。当時開発したメソッドは、今も、そのまま動いています。25年以上生き残っている開発環境は珍しい。コンパイラも標準装備。ドキュメント性はとても高いです。XEADと連携できれば良いのに・・・

投稿: カンノカズヒコ | 2014.08.18 11:58

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: フィールドIDが全角日本語であることの意義:

« 「シンプル・イズ・ベスト」はややこしい | トップページ | 告知:「受注生産」のためのシステム開発ライブ »