今やっている仕事で使っている言語はVB.NETです。私にとっては昔のVBやExcelのVBAの経験に比べるとかなり浅いので、いまだに「VBだとこうやるんだけど、.NETになるとどうするんだっけ?」と調べることが多々あるほど(^^;)。
そんなVB.NETで微妙にやっかいなのがvbNullStringです。
vbNullString自体は昔のVBにもありましたが、あまり使わなかったんですよね。ところが今回のプロジェクトでは、「空文字("")ではなくvbNullStringを使う」というコーディング基準が定義されているので、嫌でもvbNullStringを使わざるを得ません。
空文字("")とvbNullStringは似ているようで別物です。vbNullStringってのはNull Pointerみたいなものですからね。
そのくせ、VB上ではほぼ同等に扱われるので、"" = vbNullString はTrueを返してきます。単純に空文字("")とvbNullStringを判別できないのです。では空文字("")と同じ感覚でvbNullStringが使えるのかというとそうではないのでやっかいです。例えば、空文字("")に対してTrim()を行うことは出来ますが、vbNullStringにTrim()を行うと例外が発生します。Null Pointerなんだから当然の動きではありますが、ちょっと困った(というかめんどくさい)ことになるのです。
例としてTrim()を上げたのは、今回のプロジェクトではやたらとTrim()を使う場面が多いからなのですが、基本的にStringクラスのメソッドはみんな同じだと思います。
コーディング上、「定義済みの定数があるんだからリテラルではなくそっちを使え」というのは間違ったことではありません。寧ろ推奨されることでしょう。
そもそもVBにはNothingやEmptyはあるけどNullってないんですよね。なのでDBが絡んでくるとDBNullなんてもの判断しないといけなくなったりするのでますます面倒です。全部Nullで統一してくれればどんなに楽なことか。
VB.NETは言語としてとっつきやすいとは思うので、かなり多用されていると思いますが、昔からのBasicのしがらみみたいなのも残っているので、ちょっと使いにくかったりする部分はありますね。
プリミティブ型(とはVBでは言わないのかもしれないけど、元々言語が持っているIntgeerとか)がNull値(VBで言うところのEmpty)を持てないというのも面倒なところだと思います。Variant(Object)型の変数じゃないとだめなんですよね。昔、PowerBuilderというのをやったことがありますが、言語構文はVB(当時まだVB.NETはなかった)とかなり似ているのですが、どの型の変数もNull値を持てるのがとても便利でした。特にDBとの親和性が高くなります。PowerBuilder自体、DBありきというか、DBと繋げないのなら使う意味は無いというものではありますけどね。
VB6からVB.NETになったときに、その辺のしがらみなどを断ち切ってくれると良かったのですが、そこまでは出来なかったんでしょうね。
そんなVB.NETで微妙にやっかいなのがvbNullStringです。
vbNullString自体は昔のVBにもありましたが、あまり使わなかったんですよね。ところが今回のプロジェクトでは、「空文字("")ではなくvbNullStringを使う」というコーディング基準が定義されているので、嫌でもvbNullStringを使わざるを得ません。
空文字("")とvbNullStringは似ているようで別物です。vbNullStringってのはNull Pointerみたいなものですからね。
そのくせ、VB上ではほぼ同等に扱われるので、"" = vbNullString はTrueを返してきます。単純に空文字("")とvbNullStringを判別できないのです。では空文字("")と同じ感覚でvbNullStringが使えるのかというとそうではないのでやっかいです。例えば、空文字("")に対してTrim()を行うことは出来ますが、vbNullStringにTrim()を行うと例外が発生します。Null Pointerなんだから当然の動きではありますが、ちょっと困った(というかめんどくさい)ことになるのです。
例としてTrim()を上げたのは、今回のプロジェクトではやたらとTrim()を使う場面が多いからなのですが、基本的にStringクラスのメソッドはみんな同じだと思います。
今回のプロジェクトで良く出てくるのは、メソッドの引数として渡された文字列に対してTrim()をかける必要があるという事。渡された引数の内容がvbNullStringだったらそのままTrim()出来ないので、事前に判断を入れないといけなくなるんですよね。これがなかなか鬱陶しいww。
そんな事があるので、あまりvbNullStringって使ってなかったんですよね。ただ、今回はコーディング基準で決められているのでしょうがなく使ってますが、やっぱり鬱陶しいです。コーディング上、「定義済みの定数があるんだからリテラルではなくそっちを使え」というのは間違ったことではありません。寧ろ推奨されることでしょう。
そもそもVBにはNothingやEmptyはあるけどNullってないんですよね。なのでDBが絡んでくるとDBNullなんてもの判断しないといけなくなったりするのでますます面倒です。全部Nullで統一してくれればどんなに楽なことか。
VB.NETは言語としてとっつきやすいとは思うので、かなり多用されていると思いますが、昔からのBasicのしがらみみたいなのも残っているので、ちょっと使いにくかったりする部分はありますね。
プリミティブ型(とはVBでは言わないのかもしれないけど、元々言語が持っているIntgeerとか)がNull値(VBで言うところのEmpty)を持てないというのも面倒なところだと思います。Variant(Object)型の変数じゃないとだめなんですよね。昔、PowerBuilderというのをやったことがありますが、言語構文はVB(当時まだVB.NETはなかった)とかなり似ているのですが、どの型の変数もNull値を持てるのがとても便利でした。特にDBとの親和性が高くなります。PowerBuilder自体、DBありきというか、DBと繋げないのなら使う意味は無いというものではありますけどね。
VB6からVB.NETになったときに、その辺のしがらみなどを断ち切ってくれると良かったのですが、そこまでは出来なかったんでしょうね。
コメント