プログラムの命名規約について

投稿者

投稿内容

温州蜜柑: ベテラン; 会議室デビュー日: 2005/01/24; 投稿数: 65; お住まい・勤務地: 東京都

投稿日時: 2005-02-02 22:46

私は或るシステムの開発（プログラム）を担当しているのですが、
資産のファイル名の命名規約に疑問をもっています。

例えば以下のようなファイル名にすると...
　DH01UVN001.java
　DH01UVN002.java

　public void unshu_mikan () {
　　：
　　DH01UVN001 dbmgr = new DH01UVN001( DH01UVN002.NORMAL_VALUE );
　　：
　}

のような記述をメソッドにしなくてはなりません。

クラスが以下の機能であるとすると、
　DH01UVN001　DB接続クラス
　DH01UVN002　定数クラス

　DH01UVN001.java　→　DBManager.java
　DH01UVN002.java　→　SystemConst.java

という方が自然だと思います。メソッドも以下のようになるわけです。

　public void unshu_mikan () {
　　：
　　DBManager dbmgr = new DBManager( SystemConst.NORMAL_VALUE );
　　：
　}

命名規約が不適切なら変更すればいいだけなのですが、規約を提示してくる
チームに通用した試しがありません。
可読性が低下するこの文化を打破したいのは私だけでしょうか？

七味唐辛子: ぬし; 会議室デビュー日: 2001/12/25; 投稿数: 660

投稿日時: 2005-02-03 00:30

確かに指摘はごもっともですが、クラス数が１０００個ぐらいあるような
やつでは　むずかしいです。ネーミング規則にしたがって機械的に生成するのも
それほど悪くはないです。

かつのり: ぬし; 会議室デビュー日: 2004/03/18; 投稿数: 2015; お住まい・勤務地: 札幌

投稿日時: 2005-02-03 00:49

COBOL文化を引きずっている状態ですね。
Javaの文法でCOBOL的な書き方をしているのではと想像しちゃいます。
Javaには一般的な命名規約が存在します。

その会社でしか通用しない規則や技術というのは
のちのちにトラブルの元になりますし、
メンテナンスも外注に出せませんね。

まいるどきゃっと: 大ベテラン; 会議室デビュー日: 2004/08/12; 投稿数: 135; お住まい・勤務地: 群馬

投稿日時: 2005-02-03 03:48

昔からやっちゃいけないと言われている典型的な命名規約ですね。今私のいるプロジェクトも似たような命名規約なので苦しんでいます。
古い会社のプログラムで見られることが多く、同じ悩みを持っているのは温州蜜柑さんだけではないはずです。
『プログラミング作法』『超図解 Javaルールブック』等、この事について簡単ですが言及している書籍もありますから、本屋で見かけたら目を通してみるのもいいと思います。

利点を探してみると名前をつけるのが楽というのはありますが、保守性を落としてまで採用する意味はありませんね。
名前はそのクラスの人生を決める大事なものですから、手抜きをせずに命名してもらいたいものです。

unibon: ぬし; 会議室デビュー日: 2002/08/22; 投稿数: 1532; お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)

投稿日時: 2005-02-03 09:10

unibon です。こんにちわ。

引用:
温州蜜柑さんの書き込み (2005-02-02 22:46) より: 命名規約が不適切なら変更すればいいだけなのですが、規約を提示してくるチームに通用した試しがありません。可読性が低下するこの文化を打破したいのは私だけでしょうか？

以下、9割は冗談、1割は本気ですが、可読性を低下させることを暗黙の内に期待した命名規約なのかもしれません。人力オブファスケーター(obfuscator)なのかも？

はにまる: ぬし; 会議室デビュー日: 2003/12/19; 投稿数: 969; お住まい・勤務地: 誤字脱字の国

投稿日時: 2005-02-03 09:53

引用:
温州蜜柑さんの書き込み (2005-02-02 22:46) より: 資産のファイル名の命名規約に疑問をもっています。命名規約が不適切なら変更すればいいだけなのですが、規約を提示してくるチームに通用した試しがありません。

問題意識を持つ事と改善する事は全くの別物で認識される事をお勧め致します。

趣味の話や新規システムなら納得ですが、でもこれは現実的な仕事で既存稼動資産に関するお話ですよね？
メディアから知りえた文言を単に横流してそれを提案と思っているならば、それは誰も聞き入れません。

温州蜜柑さんの意見に対して現場の視点からすれば下記７つの確認事項が即座に列挙出来ます。
そして、それぞのコストと課題等々を考えると云われている事にどれだけの意義があるのか？それは着手する程の優先事項なのか？かなり疑問です。

１．連番性の意義を確認したのか？
２．連番性は誰か具体的に管理しているのか？
３．現在の連番性は、どれ程現場に定着しているのか？
４．既にそのファイルを利用されているシステムはどうするのか？
５．具体的な命名基準はどうするのか？認定局が必要か？
６．「名は体を表す」を指針とした場合、その指針を問題無く適用できる構成になっているのか？
７．「名は体を表す」を指針とした場合、当初は「雨」だけで済んでいたのが
　　「霧雨」「小雨」「どしゃぶり」と別けて管理させる必要が発生した場合、具体的にどうするのか？

現実を否定しなければ受け入れられない様な新しい概念は、疑って掛かる事を忘れてはいけません。

コブラ: ぬし; 会議室デビュー日: 2003/07/18; 投稿数: 1038; お住まい・勤務地: 神奈川

投稿日時: 2005-02-03 10:40

しかし、幕藩体制に対する近代政・官体制、構造化言語に対するオブジェクト指向言語、
江戸幕府に対する明治政府、８０欄カードプログラミングに対するストアード・プログラミング、平成研究会派閥支配・順送り政権に対する小泉政権、天動説に対する地動説、、

総て、それまでの現実を否定するものばかりでしたが・・・

はにまる: ぬし; 会議室デビュー日: 2003/12/19; 投稿数: 969; お住まい・勤務地: 誤字脱字の国

投稿日時: 2005-02-03 17:38

ちょいと脱スレです。

引用:

コブラさんの書き込み (2005-02-03 10:40) より:
しかし、幕藩体制に対する近代政・官体制、構造化言語に対するオブジェクト指向言語、
江戸幕府に対する明治政府、８０欄カードプログラミングに対するストアード・プログラミング、平成研究会派閥支配・順送り政権に対する小泉政権、天動説に対する地動説、、

総て、それまでの現実を否定するものばかりでしたが・・・

私の認識の中では
コブラさんが列挙された事柄で否定関係が成立つのは「天動説に対する地動説」だけで、
この際の否定関係とは、片方の説を正とした場合にもう一方の理論が成立たない状態を示します。

そして他の事柄に見受けられる否定とは「手段」の事であり手段に於ける否定関係とは
双方の理論（概念）間に存在せずに理論を述べる人の中に存在しているモノです。

そして、私はこの「手段としての否定」の性質を理解し対処しなければならないと考えます。

人間は何かの知識を得る際に、知識内容とは別に知識の価値判断を暗黙的に行います。
そしてこの価値判断を行うが故に意図せず知識価値を高める思考が走りますが、
この行為が知識内容の判断を狂わせ、より一層の知識価値の急騰を求める様になります。

云わばバブル時代の金銭感覚と実質価値と一緒ですね。

っと堅苦しく最後は意味不明に語ってみましたが。如何でしょう？

[ メッセージ編集済み編集者: はにまる編集日時 2005-02-03 17:39 ]

プログラムの命名規約について

スキルアップ／キャリアアップ（JOB@IT）