コーディングが悪いというのは？

質問

http://oshiete1.goo.ne.jp/kotaeru.php3?q=1590132

のNo5の方のおっしゃっている意味が良く分からなくて質問します。

ＶＢ任せの変換になるので、コーディング的にはあまり良くありません。
というのは、コンパイラ（VBもコンパイラと言うのでしょうか？）に任せたプログラムはやめたほうがいいぞ　と受け取りました。

実際、C言語だろうがVBだろうがコンパイルする場合にはコードがどのようにアセンブラに変換され、機械語に変換されたかしっかり確かめる必要のある人（技術がある人）は最初からアセンブラで書いたほうがいい様に思います。

その手間が嫌なのでVBを使っている人がformatとvalを使い分ける明確な理由がイマイチ良く分かりません。
実行速度の問題なのならCを使えば良いだろうし、何がそこまで違うのかも理解できません。

（宣言せずに使用するよりは）int long stringをしっかり分けて使うのがいいぞ　というのと、valを使うのは良くないぞ　と言うのはまったく違う意味ですよね？　aをintegerで宣言してa=val(b)等と書けば自然とintegerになるのではないのですか？

結局、val()とformat()をきっちり使い分けるためにはそれぞれの関数のプログラムを理解する必要があると思うのですが、それぞれ関数の内容は公開されているのでしょうか？（簡単に調べられるのは使用方法ぐらいのような気もするのですが。）

回答No.7

rotesKomet · ベストアンサー

No.5です。

＞aをdoubleで宣言しておけばvalを使うのは曖昧じゃないと言う事でしょうか？
＞それでもやはりCDblを使えと言われそうな気がするのですが。

型の問題だけで言えば、Cdblは不要です。
但し、普通は、ValをやめてCdblを代わりに使用すると思います。
曖昧性はともかく、速度面からCdblの方が有利です。

Val関数は、便利そうですが、結構色々な動きをします。それを全て理解して使用するのであれば問題ないとは思いますが。

｛例｝
Val("1,000") は 1 、Clng("1,000")は 1000
Val("123a45") は 123 、Clng("123a45")は エラー
Val("123 456") は 123456 、Clng("123 456")は エラー

また、val関数とは直接関係ありませんが、浮動小数点型は扱いに注意が必要です。
Val("0.3") - Val("0.2") - Val("0.1")
Cdbl("0.3") - Cdbl("0.2") - Cdbl("0.1")
Cdec("0.3") - Cdec("0.2") - Cdec("0.1")
の結果を、他の変数に代入せずに直接出力してみて下さい。
（Val と Cdbl は同じ結果になりますが、Cdec は違う結果になります）

お礼

色々な動作をする事は理解できました。
そこまで理解していても使わない理由は速度が原因なんですね。
ありがとうございました。

回答No.10

piyo2000

ほぼ、結論は出てると思いますが
別の観点から。

VB4かVB5か忘れましたが、「Val()関数を使うとメモリリークする」という問題がありました。
なのでVal()関数に対するアレルギーというのも(その頃から使う人なら)多少はあったと思います。

少なくとも私はそうで、Val()をVB5の頃まで全く使わないで来ました。VB4でVal()を使わなかった分、挙動が分かりづらいんですよね。#7さんが挙げておられる例を、イミディエイトウインドウで確認することなく全て分かっている人というのは少ない・・・というか、まずいらっしゃらないのではと思います。

一方、CInt()やCLng()の入力/出力は、#7さんが例で出されているように直感的で分かりやすいですし、少しでも間違ってるとエラーになるのでバグの混入を比較的防げるというメリットもあります。Val()はまずエラーになりませんので、バグに気づきにくいということになります。

もともとの質問である「001」→「1」という変換であれば、Val()を使うのは間違いではない・・・と思いますよ。
私も、ちょっとしたテストプログラムであればそうすると思います。CInt()などだとエラートラップやIsNumericなど余計なコードを書かないといけなくなったりしますし・・・

ただ、「(入力が限定されている状況であればValでも良いと)分かっていて使っている」ならVal()でいいのですが、
そうでない場合は・・・お分かりですよね(^^;
それも経験のうちではありますが。

補足

気づきにくいような場所に使うというのは、実際のデバックの時にその実験をしない事が多いので、結局cintでもバグとして通り過ぎるんじゃないかな？と思いました。

何故VB任せと言っていたのか、その理由が解ったので今後に生かして行こうと思います

回答No.9

Wendy02

こんばんは。

#4 の私の前言を訂正させていただきます。

# CInt関数やFormat関数が、Val関数に優先するというのは、私には分りません。単に、それぞれの使い方の違いしかないと思います。

と書きながら、もう一度考え直してみました。前言を翻して申し訳ありませんが、やはり、めったにVal関数は、ちょっと使わないですね。

前の人たちにかぶることもありますが、

Val("2457")　　'(1)
Val(" 2 45 7")　'(2)
Val("24 and 57")　'(3)

こういう使い方は、皆無に近いですね。(2),(3) は、まず、確実性が乏しいし、そういう場面で、Valを使うということはありえません。空白値があるなら、空白値を調べます。

それから、(1)は、その必要性を感じません。私の場合、Double型で出力する場面なんて、ほとんどありません。必要ならば、桁に応じて、CLng や CIntでよいですから。Double型で使うような場合は、最初から、数値で扱いますね。テキストインポートで取り扱うにしても、Val を用いません。

あえてValを使うなら、

Val("&HFFFF")

文字列を10進に直すということなら別ですが、それさえ、あまり使いませんね。

＞＞関数の内容は公開されているのでしょうか？
＞というのは、HELPに載っているような内容ではなく、コードが公開されているのか　と言うことを聞きたかったんです。

それは、公開されていないですね。（たぶん）
よく使っている人にしか分らない経験値による、感覚的なものしかないと思います。

回答No.8

Freelancer

No.6です。再び回答させて頂きます。

> 俺のイメージではそれこそ「Val関数は型を特定しないことから変換に有効的」なイメージですので。

というお言葉のとおり、変換対象が数値、文字、日付などどんな型か分からない場合、Val関数は有効かも知れません。
ただ、普通は値に合った型の変数で受けますよね。数値型の変数に入れる場合でも、日付型の変数に入れる場合でも、IsNumericやIsDateなどの関数で値をチェックして、然るべき型の変数に格納して扱うのが無難なのです。

例えば、数値データだと思って、Val関数で変換したら、変換後の値が０だった。数値が入ってきてるからＯＫかと思っていたら、実は文字列のデータをVal関数で変換した結果の０だった、などということが後々発覚すると、致命的な障害になりかねません。当然、「Val関数が文字列を勝手に０に変換したんです！」などという言い訳は通じません(笑)
「型を特定しないことから変換に有効的」を逆手にとられたケースですかね。
この時、CIntなどの数値変換関数だったらエラーになりますし、IsNumeric関数で事前にチェックすれば、Falseを返してくれるでしょう。

説明が下手で、ご納得いただけないかも知れませんが、要するに個人的に障害になりえるものだという概念があるので、Val関数は使用しない方がいいと申し上げました。

No.5さん ＞ いつも適切なご説明ありがとうございます。

お礼

ただ、どうしてvalが嫌われ者なのかは分かりました。
ありがとうございました。

補足

事態がよく解りませんが、valで０になるような事態だったら、cint、isnumericを使えばなんとなく動くような事にはなりませんが、正常な動作とは言えないような気もするのですが。どっちにしろバグになってしまうのではないのでしょうか。

回答No.6

Freelancer

すみません。だいぶ波紋を広げてしまいましたね。

訂正しますと、Val関数は使っても良いです。私もどうしようもなければ使用します。
しかし、#5さんのお言葉をお借りしますと、

> もし業務としてプログラミングを行うのであれば、曖昧性を排除し、VBでも実行速度を考慮する必要があります。

ということなのです。
曖昧な処理は障害の原因になりかねないし、業務においては実行速度だけの問題で、安易にVBをCにするなんてことはしません（お金の絡みもありますし）。プロジェクトに開発規約があれば、Val関数（Variant型など）の記述があると思います。

ちなみに、先の質問に対しては、「アドバイス」という回答種類で質問者にお伝えしたまでです。その方法がいけなかったのであれば、以後改めます。
皆様、お騒がせ致しました。

補足

本人様に来ていただけるとは思っていませんでした。
ありがとうございます。

アドバイスが良くないと言う事ではなく、なぜvalが良くないのか、あの回答を見ただけでは個人的にぜんぜん理解できなかったため、質問させていただきました。（俺のスキルが無いだけです）
なので、ぜんぜん改める必要は無いと思います。

出来ればval関数の曖昧な点を教えていただけますでしょうか？俺のイメージではそれこそ「Val関数は型を特定しないことから変換に有効的」なイメージですので。

回答No.5

rotesKomet

＞数値以外を入力するとエラーを返すのはcintもですよね？

cint("0a1")はエラーになりますが、val("0a1")はエラーにはならないです。
あと、val関数は、VB4.0の頃にメモリリークを起こしていたので、何となしに避ける方向にあります。

個人の趣味でコードを書くなら、VBはお手軽に記述できますので、taunamlzさんのおっしゃる通り、楽に記述すればよいと思います。
個人的には、変数宣言もなしで全然構わないと思っています。

しかし、もし業務としてプログラミングを行うのであれば、曖昧性を排除し、VBでも実行速度を考慮する必要があります。

例えば、a=val(b)なら、valの返値はdoubleなので、少なくとも、a=Cint(val(b))と記述するがあります。
（他の言語では型が異なるのでコンパイルエラーになる場合があります）

少なくとも、自分の勤務している会社の開発規約では、Val関数は使用禁止で、Format関数も基本的にはFormat$を使用する必要があります。

補足

>例えば、a=val(b)なら、valの返値はdoubleなので、少なくとも、a=Cint(val(b))と記述するがあります。
aをdoubleで宣言しておけばvalを使うのは曖昧じゃないと言う事でしょうか？
それでもやはりCDblを使えと言われそうな気がするのですが。

回答No.4

Wendy02

こんにちは。

元の書き込みで、私は、「VB任せ」「コーディング的」という言葉が適切かどうかは分りませんし、その意味をよく理解できません。あえていうなら、そういうことは「経験的」ということしかないと思います。

Val関数ですと、その引数を無作為に入れれば、#3さん等が、ご指摘のように失敗することもある、というぐらいでしょうね。私の場合は、それは、Val関数に限ったことではありませんが、何度も何度も失敗して覚えただけで、私のような人間は、転ばぬ先の杖で教わったとしても、やっぱり失敗しなければ覚えられませんね。でも、CInt関数やFormat関数が、Val関数に優先するというのは、私には分りません。単に、それぞれの使い方の違いしかないと思います。

ただ、その元のごく短いご質問からみると、そういう可能性を示唆する必要性があるかどうか、なんとも言えません。質問から与えられた条件は、その条件がご質問者さんの想定内なら、そんな憂慮は関係ないことです。特定の条件の中で使われるものについて、想定外について考慮に入れるのは、とどのつまり、製作者側（ご質問者）の判断でしかありません。それ以上は、特に掲示板上では、[経験的に]無意味なんですね。

＞関数の内容は公開されているのでしょうか？
Help で見れば載っているはずですが……。

補足

つまり、エラー回避のコードを埋めたほうが良いと書きたかったのではないか？と言う事ですよね？
しかし、Freelancerさんはvalが良くないと言っていますよね？
「Val関数は型を特定しないことから」ここが重要なポイントだと思うのです。おそらくエラー云々ではなく、何かあるのだと思うのですが。
＞関数の内容は公開されているのでしょうか？
というのは、HELPに載っているような内容ではなく、コードが公開されているのか　と言うことを聞きたかったんです。
たとえその内容がCで書かれていようがVBで書かれていようが、コードが分かれば変換の具体的な方法が分かりますので、cintとformatとvalを比較し、cint,formatがどのように優れているのか分かりますから。

回答No.3

todo36

Cintが良くて、Valが駄目とするのは理解できないです。
文字列から文字列への変換であれば、Formatを使うのもありでしょうけど、いずれにせよ

> 渡すデータがどういう書式あるいは内容なのかを判断してやらないと予期しないエラーを招くことになります。

これを考慮する必要があります。

回答No.2

0x131cc6e

＃１です。念のため補足。

val()関数は全く使ってはいけない、という意味ではありませんよ。
元発言者の方も

＞その値がどういう性質のものなのかを考慮し

と書かれています。
val()で変換しても毎回確実に同じ結果が返されるようなデータ仕様ならval()でも問題ないと思いますよ。

回答No.1

0x131cc6e

コンパイル結果云々の話ではないですよ。

処理の結果が保証されないようなコーディングはするべきではない、という事ですね。
val()の仕様が、
「数値に変換できる部分までを数字として扱うが、%などが含まれているとエラーが発生する」
というものですので、渡すデータがどういう書式あるいは内容なのかを判断してやらないと予期しないエラーを招くことになります。

データ内容をVBの標準関数に判断させずに、自前の処理内で判断して常に同じ変換を行うようにした方がいいですよ、ということでしょう。

たとえ技術が無い人でも一定の結果が出るように処理を書かなければいけません。
なぜなら、それこそが「プログラミング」だからです。

補足

数値以外を入力するとエラーを返すのはcintもですよね？
Freelancerさんは「valを使うことが良くない事」と言っていますよね？IsNumericを使うことで回避できる問題なのですから、なぜvalが駄目なのかが解りません。

0x131cc6eさんのおっしゃっていることだと「valだろうがcintだろうが事前にIsNumeric等を使ってエラーを回避しましょう」と言っているのだと思うのですが。
それだとvalを使うことが良くないと言う理由にはならないと思うのですが。