- PR -

.NET開発のコーディング規則について

«前のページへ 1|2|3|4 次のページへ»
投稿者投稿内容
maru
ぬし
会議室デビュー日: 2003/01/27
投稿数: 412
投稿日時: 2004-07-17 22:23
こんにちは。

>というのがありますけど、intとかstrってハンガリアン記法じゃないですよね。
>VBでハンガリアン記法を使っているソースって見たことないんですが。
インターネットやいろんな書籍でハンガリアン記法（もどき？）と紹介されているのでその
ように理解しているのですが・・・？
http://dobon.net/vb/dotnet/beginner/namingrules.html

こまかい違いはあるかも知れませんが、ようはプリフィックスを付けるかどうかという話です。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2004-07-20 08:47
いくつかレスがありますので、枝の始点に。。。

引用:

Jittaの書き込み (2004-07-16 16:21) より:
ただ、画面上に配置するコントロールについては、プリフィックスを決める方がよいと、私は考えます。


　GotDotNet Japanのほうで、「Tipsカレンダープロジェクト」というプロジェクトが動いています。その中でハンガリアン記法をTipsとして取り上げられた方がいらっしゃるのですが、他の方より、「MSDNの中でハンガリアン記法が否定されている」などにより、没になっています。それに対して、「画面系コントロール（あちらでは特にWeb系）では有効ではないか」と取り上げたのですが、画面系コントロールもやはり作ることができるし、そもそも「特定のプリフィックスを付けるというルール作りが品質を落とす」というご意見もあります。
　これはもう、プロジェクトや職場での慣習や、何を持って品質を作り込むかという哲学的なところにまで発展する問題と思われるので、深く追求することは避けたいのですが、「なぜ、"画面系コントロールについては"プリフィックス（またはサフィックス）を付ける方がよいか」というところをお伺いしたいと思います。

　私の理由は、

  • 画面系コントロールは、「ユーザへの表示」と、「ユーザから入力」がセットになっていることが多い
  • そのセットは、「同じ名前」で統一した方がわかりやすい
  • しかし、まったく同じ名前は使うことができない
  • そこでプリフィックスにより、方向を切り分ける

といったところです。「電話番号など、入力が複数に分かれている場合は？」というご意見もあるのですが、その場合はコントロールを作ったり、サフィックスで逃げます。。。
object
ぬし
会議室デビュー日: 2002/03/20
投稿数: 338
お住まい・勤務地: 香川県高松市
投稿日時: 2004-07-20 12:17
objectです。

>Jittaさん（投稿日時: 2004-07-16 16:21）
>キャストしたら意味がない、インタフェイスや継承元クラスでアクセスするとかえってじゃまになるetc...
>だと思うのですが、いかがでしょう。
「キャスト」は「型」を殺している訳ではなく、「有効変換」をしてる訳ですよね。
そういう意味では、「変換前後の型」が明示されている事にこそ意味があるのではないでしょうか？

>Jittaさん（投稿日時: 2004-07-20 08:47）
>他の方より、「MSDNの中でハンガリアン記法が否定されている」などにより、没になっています。
>それに対して、「画面系コントロール（あちらでは特にWeb系）では有効ではないか」と取り上げたので
>すが、画面系コントロールもやはり作ることができるし、そもそも「特定のプリフィックスを付けると
>いうルール作りが品質を落とす」というご意見もあります。
私は、「ハンガリアン記法」を使っています。

理由は、
コードをインスタンスの単なる「リンク」ではなく、「プリフィックス」によって、「型関連情報」を同時に「ソース」に記述したいからです。
#「IntelliSense」の存在云々という話も聞きますが、これは単なるツールであり、「ソース上のコード」
#と同列に扱うべき問題ではないと私は思います。
#実際、「IntelliSense」の援助で「型etc.」が分かったとしても、それはまるで「ルーペ」で覗く世界で
#はないでしょうか？
#私は、ソースコードを「俯瞰」出来る事を大切にしたいと思っています。

そいう意味では、私は「Presentation」上の単なるコントロールである「画面系コントロール」より、
「Abstraction」、「Control」を「ハンガリアン記法」で記述する意味の方が大きいと思います。
#「PAC」を例に考えました。

「MS」は「大文字の使用スタイル」として
1）Pascal 形式
2）Camel 形式
3）大文字
を3つの規則としてあげています。
でも「Camel 形式」は「Pascal 形式」の「一つの特異形」ではないでしょうか？
この様な「表面的な形式」をまるで「カテゴリ」であるかの様に採用している「MS」の常識を私は疑います。

それから、これは私の想像に過ぎないんですが、
「ハンガリアン記法」の不採用は、「Camel 形式」の採用に原因がある
のではないでしょうか？
#確か、どこかで「Camel 形式」を標準で採用してましたよね？

また、「名前付けのガイドライン」の中に「CLS」の影響がある様な記述があるのも気になりますね。
「名前付け」は、「クラス」の本質に関わってくる問題だと思います。
「名前空間」の概念が必要と認められた時から、「大小文字」の区別は「標準」だと思います。
それにも関わらず、「大小文字」を区別しない言語処理系の影響が前面に出て来る所には、少し納得出来ないものがあります。
#現在に於いて、「大小文字」を区別しない仕様に拘る意味は何？
#コンパイルオプション等で対応は出来ないの？

>「特定のプリフィックスを付けるというルール作りが品質を落とす」
この様な意見は、いつの時代でもあると思います。
兎に角、ソースの記述に関しては、「MS」が責任をとってくれる訳ではありません。
最終的には、「個人」、或いは「会社・組織」の自己責任で決定すべきであると私は思います。

最後に、「長くても分かり易い名前」に、私は個人的に反対です。
「Identify」出来ないのでは困りますが、
かと言って、
直感的に把握出来ない程に長い名前が良い
とも私は思いません。

繰り返しますが、私は、ソースコードを「俯瞰」出来る事を大切にしたいと思っています。


[ メッセージ編集済み 編集者: object 編集日時 2004-07-20 13:51 ]
MMX
ぬし
会議室デビュー日: 2001/10/26
投稿数: 861
投稿日時: 2004-07-20 13:46
ファイル名にも拡張子はあるし（拡張子なしが「より」便利と思う人の割合は？）
XML要素にも 名前空間プリフィックス はあります
変数名にもハンガリアン記法があって邪魔にはならないと思います。
（変数名の文字属性とかで区別できるのなら別ですが、例えば、
ファイル小アイコンのようなものを変数名の横に自動で表示できたら）
---------------
「厳密な型は世界を救う」と主張する人はそうかもしれないが
、厳密な型を表現できないのでダメと言うのはどうか？
厳密な型の数は多すぎて処理できないが
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 追加
型付きのXMLデータを扱う分野（XQuery,XPath2.0など）は
ハンガリ的プリフィックスがいっぱいです。
---------------
プリフィックスは書くのには役に立たないが
読むのには役に立つ？ 処理の分野によるかも

[ メッセージ編集済み 編集者: MMX 編集日時 2004-08-19 12:29 ]
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2004-07-20 15:05
引用:

objectさんの書き込み (2004-07-20 12:17) より:
引用:

キャストしたら意味がない、インタフェイスや継承元クラスでアクセスするとかえってじゃまになるetc...だと思うのですが、いかがでしょう。

「キャスト」は「型」を殺している訳ではなく、「有効変換」をしてる訳ですよね。
そういう意味では、「変換前後の型」が明示されている事にこそ意味があるのではないでしょうか？

　う〜ん？
　「Statefull」というインタフェイスを作りました。これは「（特定のトリガーの後）変更があったかどうか」を知ることができる手段を提供します。このインタフェイスを「画面上のコントロール」と、「データベースのコピーを保持するクラス」が実装しています。ここでStatefullにキャストして使う側は、元のクラスがどんなものであろうと、「変更があったかどうか」を知りたいのです。また、後でソースを眺めたときも、「ここでは、変更の有無を調べている」ことがわかればそれでいいし、それ以上は必要ない、と思います。
　Statefulインタフェイスで受けている箇所は、プリフィックスとしてstateとか付けなくても、そのものであることが宣言部分で一目でわかります。また、こうしてキャストして受ける以上、Statefulインタフェイスで提供される以上のことを知る必要はないはずで、それはスーパークラスにキャストして受ける箇所でも同じでしょう。

　つまり、どんなクラスであろうとこういう操作をしたい、あるいはこれだけの値が保持されていれば必要なことができる、という設計がスーパークラスやインタフェイスにされているべきではないでしょうか。


　とはいえ、確かに継承ツリーを知りたいときがあります。例えば、.NET Framework、というよりC++からJavaに移っている私にとって、Javaの列挙Enumlationが、C++とまるっきり違うことは大きな驚きです。単にjava.utilではなく、java.util.iterate.Enumlationとかと定義されていれば、使ってから驚くことはなかったでしょう
　これは、言語のスタンダードとして用意されているクラスなのか、プロジェクトなどでローカルに用意したクラスなのかで変わってくるとは思います。スタンダードなものでしたら、１度憶えれば済みます。他のプロジェクトでも同じものを使うのですから。


引用:

コードをインスタンスの単なる「リンク」ではなく、「プリフィックス」によって、「型関連情報」を同時に「ソース」に記述したいからです。
#「IntelliSense」の存在云々という話も聞きますが、
#これは単なるツールであり、「ソース上のコード」と
#同列に扱うべき問題ではないと私は思います。
#私は、ソースコードを「俯瞰」出来る事を大切にしたいと思っています。

　型の関連情報は、私はドキュメント上に記載すべき、と思うのです。Javaだと、javaDocですか？それで、少なくとも継承関係については正しく表現されますし。
　メソッドが、単一の責務を行うのに十分短かく、かつメソッド名が十分に考察されて付けられているなら、変数名に型情報などのプリフィックスがついている必要はない、そう思います。


引用:

最後に、「長くても分かり易い名前」に、私は個人的に反対です。
「Identify」出来ないのでは困りますが、
かと言って、
直感的に把握出来ない程に長い名前が良い
とも私は思いません。

確かに。まぁ、これは『プログラミング作法』で説明されているような内容、ということで。
甕星
ぬし
会議室デビュー日: 2003/03/07
投稿数: 1185
お住まい・勤務地: 湖の見える丘の上
投稿日時: 2004-07-20 15:14
プレフィックスを付ける価値っていまどき無いですよ。

私にも型がわかるようにプレフィックスを付けていた時期がありました。C++での話です。自分で作った型やフレームワークから継承した型にそれぞれユニークなプレフィックスを割り当てていきました。もちろん参照と実体ではプレフィックスを変えます。

そしてまもなく挫折しました。長くなりすぎるんですよ。それこそ平気で「lpnumedtctlStock」なんて変数名が現れてしまうんです。直ぐに逆方向流れが始まったのはいうまでもありません。「クラスの種類なんて分からなくて良し、実体か参照かわかれば良いや」「スカラー変数は数値か文字列か浮動少数か判れば良いや。そもそもshort intとかfloatなんて普通は使わないし」「誤って別の型を代入した時には、高い確率でコンパイラがエラーを出すし」と言うわけでどんどん単純化していきました。結局最後には「obj,lp,sz,n,f,w,dw」しか使わなくなりました。

JavaやC#になると、そもそも数値型ですら継承可能なクラスになる訳で・・・Stringを継承したPostCodeクラスなんて作った日には、昔経験した長いプレフィックスが現れるのは時間の問題です。クラスについてもガベージコレクタがメモリの管理をしてくれるので、参照か実体かを強く意識をする必要もありません。

今後、私自身はプレフィックスは付けないでしょう。変数名でそこに格納されているのが何なのか判る様な変数名を付けるだけで十分ですよ。
未記入
大ベテラン
会議室デビュー日: 2003/11/24
投稿数: 121
投稿日時: 2004-07-20 17:40
プリフィクスを付けると長くなるってんなら、
色付けできたら良さそうだと思いませんか？

最近の IDE はかなり賢いから、XXXXX のサブクラスのインスタンス変数は
○○色で表示するなんて簡単に実現できそうな気がするけど。
object
ぬし
会議室デビュー日: 2002/03/20
投稿数: 338
お住まい・勤務地: 香川県高松市
投稿日時: 2004-07-20 18:43
objectです。

>Jittaさん
>つまり、どんなクラスであろうとこういう操作をしたい、あるいはこれだけの値が保持されていれば
>必要なことができる、という設計がスーパークラスやインタフェイスにされているべきではないでし
>ょうか。
私も、「必要」な情報は絶対的に大切だと思います。
でも、「プリフィックス」を付けるかどうかは、
「十分」な情報も大切だ
という話ではないでしょうか？

「実際」インスタンスの「振る舞い」は、「クラス（型）」に記述されてる訳ですから！
#それに、恐らく必要な情報だけでは、「リファクタリング」は出来ないと思いますよ。


>型の関連情報は、私はドキュメント上に記載すべき、と思うのです。Javaだと、javaDocですか？それで、
>少なくとも継承関係については正しく表現されますし。
>メソッドが、単一の責務を行うのに十分短かく、かつメソッド名が十分に考察されて付けられているなら、
>変数名に型情報などのプリフィックスがついている必要はない、そう思います。
私も、「ドキュメント」に記載する事には、全く反対しません。
でも、
「コード」上にも「クラス（型）」情報位を書こうよ
という話です。

それに、私の場合、最初に「ドキュメント」を一瞥位はすると思います。
でも、後は「コード」を眺めるのが一番多いのでは無いでしょうか？

それから、
「メソッドが、単一の責務を行うのに十分短かく、かつメソッド名が十分に考察されて付けられている」
は、「プリフィックス」とは余り関係が無いのではないでしょうか？
「プリフィックス」は、「型」情報を示す訳ですから、

言わば、
犬の「太郎」と人間の「太郎」がいた場合、
本当に「太郎」だけで良いの？
という話だと私は思いますよ？
«前のページへ 1|2|3|4 次のページへ»

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