セミナーで良く出てくる質問に、こういうものがある。
「変数名やサブプロシージャ名には、漢字やひらがな（いわゆる、『2バイト文字』は使えないのですか？」
結論から言うと、使える。
例えば、以下のサブプロシージャは、問題なく動作する。
Sub 練習問題1()
Dim 消費税率 As Double
Dim 単価 As Long
Dim ロット As Long
消費税率 = 0.05
単価 = 100
ロット = 5
‘以下で、支払総額をセルA1に記入
Range(“A1”).Value = 単価 * ロット * (1 + 消費税率)
End Sub
しかし、このマクロは、少なくとも以下の点から見てあまり好ましくない。
[1]
開発効率が著しく落ちる。
変数名を書こうとする都度、[半角/全角]キーを押して、半角全角を入れ替えなくてはならない。
変数名を書き終わったあとも同様。
[2]
VBは2バイト文字でない世界の人が作ったプログラミング言語だし、そこのロジックの部分で2バイト文字を登場させると、何かと不都合が生じる可能性が高い。
実際、変数名、サブプロシージャ名に2バイト文字を使ったくらいでは問題はないが、「プロジェクト、コントロール、フォーム モジュールなどの名前に日本語の文字を使用した際に、予期しない動作をする」という問題はある。
参考: http://support.microsoft.com/kb/418924/JA/
Microsoftがマクロ・Excel VBAで2バイト文字をサポートしたのは、しょせん、後付けで無理矢理やったこと。
そんなものをあまりアテにするべきではない。
[3]
カッコ悪い。
上記のサブプロシージャのような、変数名、サブプロシージャ名に2バイト文字を使っているマクロを見ると、デキる人には「コイツ、へたくそそうだなぁ～」と思われる。
そう思われる理由は、「上記の[1]、[2]のような問題があると知っていてやっているなら、センスが悪すぎる。知らないでやっているなら、基礎的なリテラシーに問題がある」と思われてしまうから。
– – –
かいつまんで言うと、
[1]
「要領の悪い書き方しているな～、コイツ」と思われる。
[2]
「ITリテラシー的にイケてないな、コイツ」と思われる。
[3]
「これを書いたヤツは、要領が悪くて、ITリテラシー的にイケてないヤツなんだな」と思われる。
ということだ。
だから、変数名やサブプロシージャ名に2バイト文字を使うのは、やめたほうが良い。
– – –
ここで、受講生に[3]の理由を説明すると、セミナー会場で、いつも笑いが起こる。
その多くは、「何もそんなことで」という感じの、やや失笑気味な笑いだ。
しかし、僕が続けてこう言うと、たいていの場合、受講生の顔は急にシリアスになる。
「あなたが書いたマクロを、いつか誰かが見て、そして、その感想を他の人に言いふらされてしまうですよ」
「○○さんて、『マクロ得意です！』とか言っていたのに、中身を見たら、こんなだったんだぜ」
それか、
「○○さんて、『マクロ得意です！』とか言っていたけど、中身を見て『さすがだ！』と思ったね！」
どっちがいいですか？
– – –
あなたが書いたマクロは、あなたが異動した後も、その職場に残る。
引き継ぎをした後も稼働し続けるのだとしたら、あなたの仕事のクオリティは、そのマクロの中身で評価されることになる。
そのとき、せっかくロジックはきちんとしていたとしても、
Dim 消費税率 As Double
なんて書いてあったら、もうおしまいだ。
ITリテラシーが高く、仕事のデキる人は、そんなマクロを見た瞬間、「こりゃダメだわ」と思うことだろう。
逆に、人から「さすがだ」と思われるようなマクロを書いていると、あなたがその職場から離れた後も、そのマクロが、あなたのよい口コミを起こし続けてくれる。
いわば、あなたがその職場を去った後も、あなたが残した分身が、あなたの評判を押し上げてくれるのだ。
そういう仕事をしていると、当然、キャリアアップもしやすくなる。
変数名を分かりやすく書きやすいものにする、インデントをそろえる、サブプロシージャを分割して使い回せるようにする、…。
多くのテクニックがあるが、それらをきちんと使いこなせれば、単に「マクロを書けるようになる」というだけでなく、あなたの知らないところであなたを助けてくれる分身を作ることになる。
逆に、そんなことにはおかまいなしで「動けばいい」という発想で、ITシステム開発の作法を無視したマクロの書き方をしていると、あなたがその職場を離れた後、あなたの評判を押し下げる要因になる。
こういうところは、「Excelマクロ・VBAを書くことをどうキャリアアップに活かすか」という視点で見るととても大事なことだ。
実は、達人養成塾が力を入れて教えていることは、まさにそういうところ。
こういうところの発想がしっかりしているからこそ、「Excel VBA・マクロを駆使してキャリアアップ、年収アップする」という話は現実的なものとなる。
1. 分かります！
自分も仕事で
マクロ組んだりしてするので、
[3]の理由が良く分かります（笑）
ソースを開いて
変数名がすべて日本語だと・・
どうしても素人っぽい
印象を持ってしまいます。
市販本ののサンプルなどに
日本語で書かれているのが多いのも
原因なのかもしれませんね。
初めて触る方には、パッと見て
分かりやすいのかも知れませんが・・
http://ameblo.jp/yu-minase/
私は、職業的にマクロも非常に沢山(数百本)書いていますが、変数名やプロシージャ名には日本語を使っています。以前は、英語名を使っていましたが日本語名にした方が遥かに保守が楽だと感じています。やはり母国語を使うことは余分な事に頭を使わない分有利だと思います。ということで開発効率が落ちるというのは的外れだと思います。
素人ポイとかイケてないカッコ悪いとかの感覚的な事で判断するのは、職業的にシステム開発を行っている者としてはむしろ幼稚さを感じます。論理的な視点で話が出来ていないということです。
また、少なくとも私に関する限り(多くの人にとっても)英語圏の人が日本人が作ったシステムを保守する可能性は低いです。それにVBAの中にSQLの使用を含めた場合、どっちにしてもテーブル名やフィールド名に日本語が使用される事が多いので国際性に関する議論は無意味です。この件については、私も昔検討したことがありますが、この結論に到りました。
更に日本語を使用していて開発システムに不具合があったこともありません。
コメント、ありがとうございます。
[a] 可用性面でのリスクを考慮しない
[b] [半角/全角]変換キー打鍵の手間を無視する
[c] IMEダイアログからの所望する2バイト文字呼び出しにかかる手間を無視する
[d] 目を酷使することの負荷を無視する
[e] ショートカットキーを使わない
という制約下であれば、2バイト文字でもそうでなくても、同条件かもしれませんね。
以下の観点で、僕の考えを示します。
[1] 可用性面でのリスク
[2] コーディングにかかるコスト
[3] 可読性
[1] 可用性面でのリスク
2バイト文字のほうが、システム仕様変更/連携時により高リスクと考えます。
例えば..。Office2000のころに完全になくなったはずの2バイト文字利用にかかる問題が、Office2016では再燃しています。
ref[1-1]:
Access 2000 または Access 2002 でクエリの抽出条件に 2 バイトの関数名を指定するとエラーが表示される→
回避策：ユーザー定義関数名には 2 バイト文字を使用せず、1 バイト文字のみを使用します。
https://support.microsoft.com/ja-jp/help/418090
ref[1-2]:
Office 2016 バージョン 1708 以降で日本語の VBA モジュール名を含むファイルを開くとエラー
暫定対応手順：以前のバージョンなどでモジュール名およびフォーム名を半角英数字に修正してください。
https://blogs.msdn.microsoft.com/office_client_development_support_blog/2017/08/23/ver1708-issue-japanesenamevbamodule/
こういう事件が現実に起きています。
「金輪際、同様の問題は再発しない」とは言い切れません。「今回直ったからもう大丈夫だろう。MSも仕様として保証しているし」なんて言えません。
だって、Office2000のころになくなったはずの問題の再燃なんだし。
「MSがすぐにパッチを配布するし、一時的な問題だから大丈夫だろう」というようなものではないということは、ある程度の経験を積まれた方でしたらご理解いただけるかと思います。
もっとも、こんな問題の露呈を待つまでもなく、リスクの度合いで言えば、
1バイト文字 >= 2バイト文字です。
イコールになることも、不等号の向きが逆になることもあり得ません。
他アプリとの連携を考えると、2バイト文字のほうがさらに高リスクになります。
たとえば、「C#やVB.Netとかのアプリからそのエクセルファイル内の所定のモジュール内にある所定のプロシージャを実行させる」みたいなプログラムを書くことになったとしたら、言うまでもなく、うまく動かないリスクはもっと高まります。
このことから、僕は、モジュール名に2バイト文字を使っているプログラムを見ると、
「なんだって、こんな、高リスクな方法を採るんだろう…これ書いた人、経験が浅くて、他人が口約束でする仕様の保証とかすぐに真に受けちゃうんだろうな…。まー、それで痛い思いしたことないんだろうな。いつか痛い目見るだろうけど、まあ、言っても分からなそうだから放っておこう」と思ってしまいます。
[2] コーディングにかかるコスト
2バイト文字を変数/プロシージャ/モジュール名に使うと、コーディングにかかるコストが上がると考えます。
分かりやすい例を、以下に3つ挙げました。
[2-1] 定義済み変数/プロシージャの記載にかかる負荷
[2-2] 定義済み変数/プロシージャの検索にかかる負荷
[2-3] モジュールの選択にかかる負荷
[2-1] 定義済み変数/プロシージャの記載にかかる負荷
変数/プロシージャ/モジュールの記載にかかる負荷について比較します。
例えば..。以下を比較してみます。
Dim gyobango ‘[方法A]
Dim 行番号 ‘[方法B]
ここで、定義済みの上記変数をプロシージャ内で書くとして：
[方法A] なら、入力補完機能を使って、4ステップです
[g], [y], [ctrl] + [j], [tab]
↑モニターを見ないでも書けます。せいぜい、ぼーっと見ているくらい。
[方法B] だと、、以下のどちらかでしょうが…。いずれにしても、[方法A]よりだいぶ手間がかかります。
[半角/全角], [g], [y], [o], [b], [a], [n], [g], [o], [enter(*)], [半角/全角] (11ステップ)
[半角/全角], [g], [y], [o], [enter(*)], [ctrl] + [j], [tab], [半角/全角] (8ステップ)
(*)[方法B]では、[enter]キーを押す前に、変換候補内で所望の漢字が表示されているのを視覚的に確認する作業が発生します。
さらに、状況によっては、 変換候補から「行番号」という文字列をモニターをガン見して探し、選択しなくてはならないかもしれません。
定義済みの変数なりプロシージャなりを記載する都度、この「キーボード入力工数」と「モニターをガン見して確認」の分だけ、よけいな負荷がかかります。
見た目に分かる工数以前に、半角と全角の間でモードが切り替わる都度、脳にもストレスが生じます。その分、コード全体のロジック等、より集中したいことへの意識の集中ができなくなります。
僕は、この入力時の打鍵数、視覚的負担、集中して選択する作業の負荷を重大と考えます。
「1つのアプリケーションを作る間に、定義済みの変数のうち比較的変数名の長いものやプロシージャの名称を書く回数」を仮に50回として、300個のアプリケーションを作ったとしたら、15,000回の作業で上記[方法A]と[方法B]の工数の差が生じます。
[半角/全角]キーを押す回数だけでも、30,000回の差が生じるわけです…。
[方法A]と[方法B]の2つ目の方法との差は5ステップですので、試算するなら、15,000 x 4 = 60,000ステップの差。これにさらに、「モニターをガン見する」という目の負担の大きいアクションが15,000回加わります。
僕なら、それを想像しただけで気が遠くなります。
こういうわけで、僕は、変数やプロシージャの名称に2バイト文字を使っているプログラムを見ると、
「なんだって、こんな、わざわざ書きにくい名称にするんだろう…これ書いた人、[Ctrl] + [J]とか使わないで、いちいち半角/全角変換して、モニターガン見してコード書いてるのかな？途方もない高コストだな…。指も疲れるし目も疲れるし、精神的にも負担が大きいし…。ご苦労なこった」と思ってしまいます。
[2-2] 定義済み変数/プロシージャの検索にかかる負荷
定義済み変数/プロシージャの検索にかかる負荷について比較します。
例えば、どこで再利用されているか分からない（or 記憶から抜けてしまった）、定義済みの以下の変数のどちらかを検索ダイアログから探す手間について考えます。
Dim gyobango ‘[方法C]
Dim 行番号 ‘[方法D]
ここで、 [ctrl] + [f] で検索ダイアログを表示し、ダイアログ左下のオプションボタンから検索対象範囲を選択し、検索文字列入力用のリストボックスに移動するまでは共通として、それ以降を比較すると：
[方法C]
[g], [y], [alt] + [n], [esc], [f3], [f3], …
[方法D]
[半角/全角], [g], [y], [o], [enter(*)], [半角/全角], [alt] + [n], [esc], [f3], [f3], …
[方法E]
モニターをガン見し、プロシージャの流れ全体を目で追いつつチェック(ショートカットキーを使いこなせる、まともに量をこなしているそれなりりスキルを持つプログラマーにはあり得ない挙動ですが…。いちおうこの方法も載せておきました)
[alt] + [n] 以降は一緒ですが、それ以前で比べると、[方法C]では2ステップ。[方法D]では6ステップで、かつ、[2-1]の[方法B]と同様、やはり、モニターガン見が必要。
また、先程と同様、[方法D]では、視覚的負担も加わります。
「gy」ではじまる変数は他にもあるかもしれないだろ！という疑問も出るかもしれないので、いちおう念のため補足しておくと…。それについては、「行」ではじまる変数もほかにもあるかもしれないのでどっちもどっち。
「gyobango」という文字列できちっと検索したかったら、もちろん検索ダイアログで「gyobango」と入力してもいいですが…。
場合によってはより省エネな方法もあります。
すなわち、「gy」ではじまる文字列を[f3]で検索していくうち、「gyobango」の一部が選択された状態になったら、そこで [ctrl] + [shift] + [→] で全体を選択。それから [ctrl] + [f]で、検索ダイアログに「gyobango」という文字列がすでに埋め込まれている状態を得られます。あとは同じ。
[f3] は、逆順に検索するなら， [shift] + [f3] です。
僕は、[方法C]と[方法D]の入力時の打鍵数、視覚的負担、集中して選択する作業の工数の違いからくる負荷の差もけっこうバカにならないと考えます。
コメント主さんも、種々のアプリで、例えば「font」と「フォント」だと、どっちのほうが検索ダイアログから検索するときに面倒くさいか？は体感的に分かるかと思います。それと同じことがvbaの変数名等でも言えます。
定義済みの変数/プロシージャを探してきて「どこで変数の値を設定しているのか？」とか「どこでその値を活用しているのか？」、「どこでプロシージャを呼び出しているのか？」とかをざざっと確認するのであれば、[方法E]のような、モニターをガン見して識別するなんてやり方があり得ない。
変数やプロシージャの名前が半角か全角か？無関係に、[f3]のショートカットキー連打していって、範囲選択された場所を目で追っていくのが簡単ですし、コメント主さんもそうされているのでは？と期待します。
ということで、変数名/プロシージャ名のビジュアルが半角か？全角か？自体は、定義済み変数やプロシージャを探す手間に影響を与えません。（そもそも[f3]つかってざっとレビューしているなら、モニターガン見しないから）
が、VBEの検索機能を使ってささっとチェックしようとすると、半角と全角では検索にいたるまでの工数で差が生じます。
このことから、僕は、変数やプロシージャの名称に2バイト文字を使っているプログラムを見ると、
「なんだって、こんな、わざわざ呼び出しにくい名称にするんだろう…。これ書いた人、検索ダイアログ使うときに面倒くさいだろうな…。いや、そもそも、普段から、変数とか探すときに、モニターガン見してるのかな？ご苦労なこった」と思ってしまいます。
[2-3] モジュールの選択にかかる負荷
「所望するモジュールを開く」という作業にかかる負荷について比較します。
[方法C]
以下のモジュールを有するエクセルファイルがあるとします。
module名: foo
module名: fuga
module名: hoge
module名: piyo
このとき、モジュール「hoge」を開きたければ、以下の操作で可能です。
[ctrl] + [r], [h], [enter]
モジュール「fuga」は「foo」というモジュールもあるので[f]だけでは選べませんが、以下で十分。
[ctrl] + [r], [f], [u], [enter]
↑この操作は、プロジェクトエクスプローラを見ないでもできます。
「プロパティウィンドウの高さがかなりあって、プロジェクトエクスプローラ内の標準モジュールのリストが見えない」なんてときにも、まったく問題ありません。所望するモジュールをきちんと開けたのか？の確認は、必要であれば、VBEウィンドウ上部に表示されるアクティブなモジュールの名称で確認。
[方法D]
ところが..。以下のモジュールを有するエクセルファイルがあるとします。
module名: ぴよ
module名: ふー
module名: ふが
module名: ほげ
このとき、モジュール「ほげ」を開こうとすると、以下の作業が必要です。
[ctrl] + [r], （目視で「ほげ」を見つける、そして、そこまで[Home]キー[End]キーなりカーソルキーなりを組み合わせて移動する）, [Enter]
「ぴよ」、「ふー」、「ふが」、「ほげ」ならアスキーコード順がなんとなく想像つきますが。
漢字だったらもうアウト。小さい文字を凝視して確認することになります。
ここで、前者では[h]を押すだけというほとんど反射だけで済む作業だったものが、後者では、「プロジェクトエクスプローラにある細かい文字を凝視する」という高負荷の作業に置き換わっています。ていうか、そもそも、それ以前に、プロジェクトエクスプローラの中身がある程度見えていないと使えない方法というだけでアウトです。
僕は、このモジュール選択時の打鍵数、視覚的負担、集中して選択する作業の負荷を重大と考えます。
そんなわけで、2バイト文字で名称の書かれたモジュールを見せられると、僕は、自分がモジュールを選択するシーンを想像するだけで、イライラしてきます。
「よくこの人、こんなモジュール名で平気だな…。よほど身体感覚が鈍感なんだろうな」というのが正直な感想。
「プログラムを書いているときには、コードの中身のことを考えることに極力集中したい。また、するべき」ということについては、合意いただけるかと思います。
上で示した[2-1], [2-2], [2-3]のいずれも、集中力をいたずらに消耗させ、「極力集中したいこと」への集中を妨げる要因になっています。
ということで。
ここまでに挙げた
[1] 高リスク
[2] 書くにも呼び出すにも利用状況を調べるにも面倒くさい
ということだけでも、変数/プロシージャ/モジュールの名称に全角は非推奨というには十分かと思います。
[2] については、この文章を読まれた方のVBEの各種開発支援機能の使いこなし度合いや、それにより視覚に過度に頼らないでコーディングすることの優位性を実感されているか？によっては、納得感は急には得られないかもしれませんが。
例えそうだったとしても、[1]についてはまずは同意いただけるのではないかと思います。
ということなので。
２バイト文字満載のソース見せられて「この人、どう？これ書いた人の力量について、どう思う？」と僕が聞かれたとしたら…。
「この人、まあ、ガンバってるけど…。まだまだじゃない」くらいの感想を述べることになると思います。
「ガンバってるけど」というのは、「もっと簡単にできることを遠回りして、ムダに熱を発生させつつ、ムリしてカンバっている。」という意味です。
しかも、出来上がったプログラムはより高リスク。
>素人ポイとかイケてないカッコ悪いとかの感覚的な事で判断するのは、職業的にシステム開発を行っている者としてはむしろ幼稚さを感じます。論理的な視点で話が出来ていないということです。
上記[1], [2]の理由から、「素人ポイ」、「イケてない」、「カッコ悪い」という感覚を持ちました。
このエントリーで一部では、「判断の理由」では書かず、「判断の結果」のみを書きました。
正直なところ、この記事を書いたときは、コーディング経験が少ない初心者の読者にはピンとこないだろうと考えて、理由の部分をかなり端折ってしまいました。
「判断の理由を抜きにして判断の結果たる感覚的なことを書かれた。そしてて、それがあなたの現在のコーディングスタイルとマッチしなかった」となれば、納得いかないのは当然です。
不快に感じられたこと、お詫び申し上げます。
今回投稿するこのコメントが、あなたの生産性向上の資になりますよう。
あと…。最後に。
僕は、変数名については、「ローマ字」が最強と思います。
僕は英検１級を持っていますし英語力についてはかなりある方だとは思います。が、基本的に英語は変数名には使いません。ほとんどローマ字です。
日本語の範囲内でアイデアが枯渇してきたら、英語より先にスペイン語とかから探します。
Dim Gyobango
Dim Shohizei
Dim Gokei
とか、そういう感じです。
ローマ字で書いた日本語だと、英語と違って、[ctrl] + [j]でプロパティ/メソッドの一覧を呼び出したときに、欲しいものがすぐ見つかる可能性が高いですし。
「英語」は…。まあ、「英語が得意な人なら使ってもいいんじゃない？」とは思いますが。それでも、初心者には推奨しません。
以下のような、VB標準の関数名とかぶった名称のプロシージャを作る人とかが続出するので。
Sub right()
….
….
Range(“A1”).Value = “右です”
….
….
End Sub
Sub hogehoge()
Debug.Print right(“あいうえお”, 3)
‘↑なんでright関数が動かないのだ？と質問される orz
End Sub
僕自身は変数やプロシージャの名称をローマ字にすることに慣れているので、これらの定義を2バイト文字でされているとかえってひっかかりますね。
これについては、日本語以外の言語を運用する時の脳の使い方の違いもあると思います。
例えば、「英語」という自然言語でも、運用するとき、頭の中が完全に英語モードになる人と、日本語運用時の脳の使い方から離れられないままで英語を使う人がいます。
僕は前者です。頭の中が英語モードのときは会話の中に日本語がむやみに出てこないほうが僕の場合は脳にストレスがかかりません。
同様に、プログラミング言語たるVBの運用でも、頭の中が完全にVBモードになる人と、日本語運用時の脳の使い方から離れられないままでVBを使う人がいます。
僕は前者です。VBのキーワードは1バイト文字ばかりですし、頭の中がVBモードのときはコードの中に日本語がむやみに出てこないほうが僕の場合は脳にストレスがかかりません。
ただし、それは、あくまで、「僕の場合」で、「言語運用時の脳の使い方の違い」という軸で見た場合の話です。
より高度なあるいは抽象度の高い、僕にも思いもよらないような理由から、VBの中に2バイト文字で定義された変数/プロシージャがあったほうが良いという考え方もあるかもしれません。
しかし、その理由が何であれ、冒頭[1], [2]に挙げた理由を覆してまで2バイト文字の利用を推奨できるほどではないと考えます。