前提

文字列を効率的に数値変換する方法がぱっと思いつかない人。定期的なアップデートが行われないツール的なモジュール群がプロジェクト内にある人。ドキュメントの確認よりも、とりあえずコーディング、という人。Webのインターフェイスを作るエンジニアの人。

当たり前の話なんですけど、どのような言語にせよ、世界中に認知されている言語のパッケージには、ものすごーく優秀な開発者たちが集まって作成されている。これもまた当たり前だが、大半のエンジニアが思いつく程度のメソッドはすでに提供されていると考えてよい。まずは、「ある」前提で、自分の求めるメソッド（関数）がないか調べるのが大事だ。

何でもかんでも自分で作ればよいというものではない

これは自分の体験談だが、とあるプロジェクトに携わっていたときに、StringをIntegerに変換する関数が自作されていた。parseかconvertすればいいんじゃないの？と思いつつ、コードを読んでみると、nullのときは0に変換するように条件分岐が書かれていた。まさに、convertすればいいだけの話である。

Convert.ToInt32("")

この一行で事足りる。しかも、組み込みなので、自分でメンテナンスしなくてよいし、バグがあった場合はMicrosoftが修正してくれる＆動作保証をしてくれるという、おまけつきだ。

なんでこんなことになるのかというと、最初に自作関数を作った人の「無知、理解力の低さ」が根本的な原因だと思う。もちろん、人は万能ではないのだから、知らないことがあるのは当たり前。それを恥ずかしがる必要は全くない。聞くか、後から知ればいいだけのことだ。

次点としては、それを慢性的に使い続けている後続のコーダーにも問題がある。せめて、自作関数内の処理をconverには最低限しておくべきだ。早い段階で気づいたのであれば、指摘してあげるくらいのことはやってしかるべきだろう。

ParseとCovertの違い

下記メソッドだが、引数によって戻り値が異なる。

        public int GetValue(string value)
        {
            return Convert.ToInt32(value);
        }

        public int GetValue(string value)
        {
            return int.Parse(value);
        }

convertの場合は、null(Nothing)が引数となった場合は0を返してくれる。ただし、String.Emptyは空文字なのでNGだ。Exceptionのフローに入ってしまうので注意。

parseの場合は、nullもString.EmptyもExceptionのフローに入ってしまう。

こう見ると、convertのほうが性能がよさそうに思えるが、セーフティにすることを考えると、結局のところTryせざるを得ないので、そういった意味で考えると、TryParseを最初から持っているparseのほうがよい。Exceptionが発生しない引数が保障されているのであれば、convertのほうがいいだろう。ちょっとした違いはあるが、Web画面の入出力は基本的に文字列になることが多いので、うまく使い分けたいところだ。

まとめ

つまるところ、本質的なところは、「どうやって実現するか」という手段を提供したお話ではない。いかに楽をするか、安全性を高めるかという保守性向上のお話だ。なるべく、「コードを書かない」ことが安全性を高めることになる。短く、簡潔に、あるもの（提供されているもの）を使う。たったそれだけのことで、品質ユーザービリティともに高まることになるので、今後とも実践していきたいと思っている。

結論はリファクタリング、大事よ、ってことかな。