どーも、話が噛み合ってないっぽいなあ。10+4の10ってどこから来たのか…
第三者のend-uさんから見ると、himajin100000とWendy02さんの話ってどう見える？(反射で回答するよりはいいかな、と)
ここからここまではhimajin100000が妥当だけど、この部分はWendy02さんの方が妥当、とか、最初から最後までhimajin100000の話が変とか。他にも、言い方や、やり方が悪い、話の対象がそもそも噛み合ってない(himajin100000はVBAの仕様どうこうで、Wendy02さんは、どうやってそれを実装しているのかの予想の話だ、とか)なんていう意見もOK
#締切日が延びているのは補足等があってから1日くらいは待とう、と思っているから。さらに延びました。
#himajin100000の方に問題が多いという判断で、かつ、himajin100000が「何が悪いかわからない」という状況に陥ったら、グダグタ続けるより一回締めきったほうがいいかな、と思うんで旨を伝えてそうするつもり。
立ち位置の違いというのでしょうか。
何回かぶつかってるようなないような...
ドキュメントを求めている質問に対し
求めてもしょうがないんじゃない？的な回答？
...いや誇張的な表現だったら謝ります以下自粛
こっちに飛び火してもアレなんで。
>求めてもしょうがないんじゃない？的な回答？
かな、とも最初は思ったんだけどねぇ…(そういう意図の回答を拒否したいなんてつもりは全くない。)
>補わないとわからないか？改変すべきじゃなかろうよ
*「求めてもしょうがない」という意味で取ると、その部分の後半と整合性が取れなかった。
*悪文かは判らないが、少なくとも自分は一発で意味を取れなかった。主語が結構省略されているが、どっちの立場かが結構変わっている印象を受けた。
*俺が勝手に曲解しているかもしれないから、補った上で意図があっているかこっそり様子見て確認しようとしていた。
*これについてhimajin100000が問題ある行動を起こしたという認識はhimajin100000にはない
>データ型の概要
Excel 2003のヘルプにはついていないみたいで、「ナニソレ」って思った。
で、掘り返してきた。コレか。
http://msdn.microsoft.com/en-us/library/gg251528.aspx
*このバイト数云々の話を俺は知らなかった。
*LenB関数が返してくる値から判断して、VB.NETと挙動がほとんど変わらないだろうと思った。
*VB.NETの方が意味が明確だと思っているし、ナニモノかわからなくなったVBAのことをVBAで語っても混乱するだけだと思った。
**演算子がそう定義されている、で終わっていれば、メンバ名の省略云々はともかく、文字列が数値より「常に」大きくなるよう、判断が変わることの話を自分は納得できてたんだけど…
**バイト長で比較するなら、文字列"11"とDecimal(14バイト)は、「それが表す数値に依らず」等号成立しないといけないはずなんだけど、どうなるかな？
冒頭から『このスレ主さんは..』って書き出しおかしいでしょう。
一体誰に向かって書いてらっしゃるのでしょうね。
日頃から不特定多数に向けたような、ROMの方もしくは読んでる他の回答者を意識したような、もしくは..．過剰な。
プライドが高すぎるのでしょうか。それゆえのトラブルが結構多いような気がします。
私も関わってるスレでいうと
まずQ5054645がいけなかったんでしょうね。
あとパターンは違えどQ5071261,Q5250696,Q5512575,Q5684309,Q6071227など
主戦場がかぶってるから仕方ないんでしょうけど。
なので迷う事なくhimajin100000さんを支持してます。
あまり気にされないほうが良いと思いますよ。
>バイト長
Variantなので
>バリアント型 (Variant) (数値) 16 バイト
>バリアント型 (Variant) (文字列) 22 バイト + 文字列の長さ
になっちゃうような気が。
ぅーん。反証したい...
#コメント削除可ですorz
ちょっと真面目に補足しておくと、噛み合ってないのはやはり
（今回スレッドのテーマとして）
・himajin100000さんはドキュメント志向
・Wendy02さんは実践志向
であるからだと解釈してます。
それと話題があっちこっち遷移してるから。
h)Rangeのデフォルトプロパティの根拠文献については解決。
W)プロパティを省略した場合に呼ばれるデフォルトプロパティが何か、
に拘るよりもプロパティを明示したコーディングをするべきであり、
そうする限りは根拠となる文献がどうあれ、意図したプログラミングができる。
（失敗事例としてDictionaryコードを提示）
h)調査対象が、プロパティを省略できない時、できる時の根拠文献を探ることに移る。
（もしくは省略時の挙動の違い）
*多分、ここまでは本流。
W)少しレスのテーマがずれ、
「数値より文字列が常に大きいとされるのは両方がVariant型の時」
という別スレ問題に対して説明コード、バイト比較。
*これは説明不足。と思う。もしくは不適切。
「2,4,8 バイトのいずれか」というのは誤解される。
その誤解で「VB.NETでいえば？」という意図確認の為の対応が生じてしまう。
本来は
Variant(数値)16 < Variant(文字列)22 + 文字列の長さ
という説明が良かった。
しかし、そもそも別スレはVariant同士の比較ではない。
Variant型とString型の比較なので『文字列比較』。
『文字列と数値の比較では、文字列のほうが大きいわけですから、うまくいくはずがありません。』
ここが
『文字列と数値の比較では、『文字列比較』になりますから意図した（数値）比較になりません。』
という表現のほうが良かった。
実は別スレのこの一文が一連のきっかけである。
が、恐らくWendy02さんは意識されてない。
「プロパティは省略しない」
「値の比較は、比較する前に文字列か数値かチェックする」
「難しい話をする必要もなく、基本的なことを守れば解決するはずです」
これには誰にも異論がない。
「省略してどうとか、それは自分の実験の中だけの話です」
そうです。そこから話が始まっています。
実験に止まらず、根拠文献があれば「仕様」という裏づけが確定します。
こういった流れからすると、
・VB.NETでの比喩
・回答文の補足付記による意図確認
・英文翻訳の解釈確認
・マナー失指摘
は傍流かと。
...さて。どう決着するのでしょう。
あるいは決着しないのか。
とりあえず私は ？ を投げてるんですが、
もちろん質問者ではないので返ってこなくても構わないです。
Variant(数値)16 < Variant(文字列)22 + 文字列の長さ
という説明が良かった。
しかし、そもそも別スレはVariant同士の比較ではない。
Variant型とString型の比較なので『文字列比較』。
『文字列と数値の比較では、文字列のほうが大きいわけですから、うまくいくはずがありません。』
ここが
『文字列と数値の比較では、『文字列比較』になりますから意図した（数値）比較になりません。』
という表現のほうが良かった。
実は別スレのこの一文が一連のきっかけである。
が、恐らくWendy02さんは意識されてない。
「プロパティは省略しない」
「値の比較は、比較する前に文字列か数値かチェックする」
「難しい話をする必要もなく、基本的なことを守れば解決するはずです」
これには誰にも異論がない。
「省略してどうとか、それは自分の実験の中だけの話です」
そうです。そこから話が始まっています。
実験に止まらず、根拠文献があれば「仕様」という裏づけが確定します。
こういった流れからすると、
・VB.NETでの比喩
・回答文の補足付記による意図確認
・英文翻訳の解釈確認
・マナー失指摘
は傍流かと。
...さて。どう決着するのでしょう。
あるいは決着しないのか。
とりあえず私は ？ を投げてるんですが、
もちろん質問者ではないので返ってこなくても構わないです。
総論賛成。ここは動きません。ただ、VBAに限定して言うならば疑問が。
*「難しいこと考えなくても常にその考え方・書き方をしていれば良い。自動的に問題が解決されているから」が俺にとっては重要。
http://takagi-hiromitsu.jp/diary/20051227.html
>だが、そのような確認作業をしないと正しいコードかどうかわからないような、プログラムの書き方をすべきでない。セキュリティ云々以前に、プログラムの開発方法論として、できるだけ局所的な視点でコードの正当性を確認できるように書くのが、近代プログラミングの基本だ。つまり、このコード断片だけ見て、問題がないとわかるように書くべき
*値として使うときはプロパティを省略しない
*オブジェクトとして使いたいときは当然プロパティを書かない
は俺にとって、その一環なのだ。だが、VBAにおいては…
*Range Objectと文字列を等号で比較した場合、エラーを投げるだろう…あれ、投げないの？
*別の機会に自分がコードを書いたときに意図せず「オブジェクトのつもりで書いたコードがVariantとして返されてしまう」というのを恐れている。(この2指針では逆は起きないはず)
*上記の2つの指針を守るだけでは「常にその書き方をしていれば、意図したコードに必ずなる」条件には足りないのか？
*他にどういう事を「常に」意識すれば「常に思ったとおりの挙動をするコードになる」の？
>あるいは決着しないのか。
させないかも(笑)。締めきれない要因の一つは、「ちゃんと反論出来ているのかなあ」ということに自信がもてないから、割とよくある。
#俺の脳内半分くらいは、「end-uさんの回答に対するWendy02さんの反応を見る」という「ことにしている(笑)」
>>だが、そのような確認作業をしないと正しいコードかどうかわからないような、プログラムの書き方をすべきでない。セキュリティ云々以前に、プログラムの開発方法論として、できるだけ局所的な視点でコードの正当性を確認できるように書くのが、近代プログラミングの基本だ。つまり、このコード断片だけ見て、問題がないとわかるように書くべき
なるほど仕様とか文献とか以前に『プログラミング基本論』なのですね。
勉強になります。
..となるとVBAの曖昧さというか不完全さはhimajin100000さんにとってかなりストレスを感じる言語になっているのでしょうね。
そうすると既定メンバの省略に対する挙動の解明は、私が思ってる以上に大きな問題を孕んでいた、という事なのですね。
Rangeの_Defaultプロパティの曖昧さが代表的なもので。
ひょっとしたらRangeオブジェクト自体の問題？
Excel固有の欠陥仕様である可能性も考えられますか。
ちょっと嫌な想像ですけど。
また
>*他にどういう事を「常に」意識すれば「常に思ったとおりの挙動をするコードになる」の？
巷の、バージョン混在が激しいという現状をも考慮しなければならないとなると、
かなり頭痛い状況ではあります。
>..反応を見る」
...７割くらいは返り値が無い可能性がある...と思ってます。:P
YES
>曖昧さ
尤も、この曖昧さは恐らく意図的に組み込まれたものなんですがね。
> http://local.joelonsoftware.com/wiki/%E3%81%AF%E3%81%98%E3%82%81%E3%81%A6%E3%81%AEBillG%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%81%AE%E3%81%93%E3%81%A8
>Silverの元々のデザインはタイプシステムに対する深い理解を必要としていたが、それはマクロを書く人たちがおよそ気にかけるようなものではなかった。
同著者の「やさしいバグトラッキング」が俺のお気に入りの記事の一つなだけに、後でその話を読んでショック受けたね(笑)
http://japanese.joelonsoftware.com/Articles/PainlessBugTracking.html
#ユーザの方に降りてくるんじゃなくて、ユーザを教育して引き上げろ。言語は理想形を追求して欲しいのだ。(いやまぁ、その「理想形」に俺のbiasがかなり入ってますが)
#当時VBAから、VSTAでVB.NETが使えるだろうという認識でいた俺は喜んだ後、かなり打ちのめされた。
http://oshiete.goo.ne.jp/qa/5482657.html
興味深いリンク先を幾つも教えて頂きました。ありがとうございます。
メジャーな話 tp://www.h3.dion.ne.jp/~sakatsu/Excel_Tips02.htm#Note
ではありますが、また違った面からのエピソードが読めて面白いです。
『間違ったコードは間違って見えるようにする』記事も、ぅーん..勉強になります。
「やさしいバグトラッキング」も良いですね。
>10.バグデータベースに新しいフィールドを追加するという誘惑を排除すること。..重要なのはこれらのアイディアを聞き入れないということだ。
プログラミング分野外でも、仕事に参考になりそう。
これは是非、玉条にしたい :D