+ 日本語コーディングしようぜ
created 2011-05-11 modified 2021-01-07
日本人プログラマなら日本語の識別子を使おうぜ
最初に言っておくと、私は、「日本語プログラミング言語」には反対だ。「もし」、とか なになに 「とは」、なんていうプログラムは、かえって読みにくい。
私が推奨したいのは、プログラムの制御を行うような予約語は英語のままで、変数名やクラス名、関数名等、識別子だけを日本語にする方式。
日本語は混ぜ書きになじむ。名称だけを日本語で、制御の予約語をアルファベットで書くプログラムは、驚くほど可読性が高いですよ。
プログラムに日本語なんてナンセンスだ、というあなたは、以下のチェック項目を読んでも、日本語識別子の使用を否定するだろうか？
チェック１：英語の語彙
もしあなたと、あなたの周りの3人が、サーフェスとサファイスとサティスファイの違いを瞬時に答えられないなら、下手な英語識別子の使用をやめるほうがいい。
...もちろん私も答えられないし、あなたのプログラムをメンテナンスする羽目になった誰かもやはり答えられないだろう。
サーフェス surface 表面 ... 描画処理に用いるメモリ領域を指すことがある。
サファイス suffice 十分に足る ... 十分条件である事柄を示す場合に使うことがある。
サティスファイ satisfy 満たす ... 条件を満たす、(コンパイラを)納得させる等の意味で使うことがある。
チェック２：短縮ローマ字
あなたは、Sbt、Kbn、
お客様の業界の専門用語には、それ自体にかなり限定的な意味があるし、相当する英語が存在しない場合もある。
もし今まで英語の識別子でやってこれたなら、あなたは純朴な世界でしかモノを作ってこなかった可能性がある。
これからソフトウェアは摘要範囲がますます広がる。そんな業界を担っていくつもりなら、下手な英語識別子の使用をやめるほうがいい。
Sbt = 種別、Kbn = 区分、
日本語識別子が使えなかったからそうしたのであって、日本語識別子が使えるなら使ったほうがよい。
追記:お客様自身が、「△△種別」と「△△区分」を、別の意味の業務用語として使い分けている場合があります。こんなとき、コンピュータ都合での英語化は誰のためにもなりません。
追記:creditとdebitについては、最初に日本語に訳した(一万円札の)YF先生がやっちまった悪例と考えるのが一般的らしく、この記事の例として不適切な例でした。→「日常の言葉のようでいて実は特殊な意味を内包する、日本語のお客様用語」を短縮ローマ字にしていたある現場の例を示したかったのでした。
チェック３：コメント行数
１つの関数において、行数で換算して4割以上をコメントに費やしているなら、まずはツールや、周辺プログラムからでかまわないから、日本語識別子の使用を試してみて欲しい。
Ruby作者のまつもと氏は、
ソースがドキュメントだ、バグもすべて書いてあるとおっしゃったそうだが、それがジョークや笑い話ではなく大真面目な常識となる世界を体験できるだろう。
チェック４：新しいプログラミング言語はUTF-8をサポートしている
あなたが現在のプロジェクトで使っているプログラミング言語は、もうすでにUTF-8の識別子をサポートしているのではないだろうか。
私はJavaが大嫌いだが、JavaとEclipseを用いるなら、日本語識別子を使うことに何の障壁もない。
WindowsでVC++を用いているなら、あなたのPCはすでに日本語識別子を問題なくコンパイルできる。
.Netも然り。
チェック５：ソースを輸出する計画はあるか
あなたが作っているソフトウェアの、ソースコードを、海外の企業に売る計画はあるだろうか。もしそうであって、自分たちの開発効率を犠牲にしてまで英語を使いたいなら、私には言うことはほとんどない。
ただ、私やあなたの下手な英語のソースは、ネイティブの英語話者にとって理解を妨げる以外の何者でもないかもしれない、という謙虚さは持っていて欲しい。
また、母国語のリファレンスマニュアルさえ満足にかけていないなら、英語のリファレンスマニュアルを書き、維持していくのはもっと大変であることも認識して欲しい。
あなたがもし、防衛省がらみのプロジェクトで報酬を得ているならば、今すぐ日本語識別子の使用を検討することをお勧めする。日本人にはプラスになり、外国の産業スパイには障壁となるからだ。（追記:そして、そのソースを海外に輸出するということはまれであろう。つまり、英語の識別子を使う意味は薄い。）
今日はここまで。
| リンク | 備考 |
|---|---|
| [迷信] 識別子に使える文字は英数字と下線のみ - きじねこ | |
| GCCで日本語識別子を使う - きじねこ | |
| 続・GCCで日本語識別子を使う - きじねこ | |
| 続々・GCCで日本語識別子を使う |
追記:
日本語識別子を使うVC++のコードを読むと、
ああ、シリコンバレーの人たちにはソースコードがこんな風に見えていたのか。そりゃ勝てねぇよ
と愕然とします。本当です。
追記2: 2011年12月
以下、別ページを内包: memo/20111202
以前、【+ 日本語コーディングしようぜ】という文書を書きましたが、ちょっと追記します。
ソフトウェアを設計・製造するという作業は、そのほとんどが、「概念に名前をつけて、コトバ（仕様書、設計書）に定着させる」作業です。
よいソフトウェアとは、利用者の要求を満たすのみでなく、その設計においても優れているものです。概念や構造が整頓されていることにより、より高い抽象度で概観することができる、可読性・可変更性が高い、そして可管理性が高いものです。しかし私たちは往々にして、よくないソフトウェアをつくってしまいます。
ソフトウェア上の概念に「適切な名前をつける」ことで、多くの問題が解決します。適切な名前をつけるには、プログラミング言語以前に人間が話す言語のセンスが必要だと思います。私たち末端の開発者が、より高いセンスを持っているのは、英語なのでしょうか、母国語なのでしょうか。
昨今、社内の公用語を英語にする、等の先鋭的な試みをされているIT企業もあると思いますが、それは日本の一部を構成する日本の企業として、日本人の雇用に貢献するのでしょうか。そして、日本の社会の豊かさに貢献するのでしょうか。
私は視野の狭い井の中の蛙かもしれません。しかし私は、ベターな道を探したいのです。
25年以上前の話ですが、あるNHKの番組がありました。案内役として坂村健先生が登場し、当時のコンピュータの状況を説明し、未来のコンピュータの姿を模索する内容でした。
番組の中で坂村健先生は、「人間がコンピュータの言語を学ぶのではなく、コンピュータが全ての人間の言語を学ぶべきだ」とおっしゃいました。
人間がコンピュータを操り、人間の世界を豊かなものにするのか、あるいはコンピュータが人間を操るのか。コンピュータは媒体であって、通信の両端には人間と人間がいます。そのことを坂村先生は強く訴えていたように思います。
坂村先生。先生はその後「超漢字」を開発されたり、コンピュータが扱う文字がユニコード化していく流れの中で、字体の細かな違いが淘汰されてしまうことに対する、文化的な観点からの懸念を発信されていたように解釈しています。25年経って、世界はどうなったでしょうか。貿易はますます盛んになり、情報の往き来も増えましたが、まだ国境はなくなっていませんし、コンピュータが全ての言語を学ぶにも至っていません。それでも、UTF-8には皆が納得できる妥協案としての光明があり、そろそろ成果を収穫できる季節に来ているように思います。
私は日本語コーディングが大好きですが、共通語としての英語の有用性については私も否定しません。
FastDBという、ロシアの方が作成されたオブジェクトDBMSを利用させていただいて、マニュアルの一部を日本語に翻訳させていただいたものをこのサイトで公開していますが、もしFastDBがロシア語で書かれていたら、私にはお手上げでした。英語で書かれていたからこそ、読むことができたのです。
Linuxの開発がフィンランドの言語だけで行われていたら、今のように花開いてはいなかったことでしょうし、私自身もLinuxからの多大な恩恵を、受けることができなかったと思います。
また、日本語で概念を整理した後、英語の識別子を考えるときに、より適切な言葉を思いつくのもよくある話です。複数の言語で考えることで、より一般的な概念に発想が着地することもあるでしょう。
さらに、自分が書いた文書を英語に翻訳することを経験することで、分かりやすい日本語で書くことを心がけるようになる、という作用もあります。
私が問題視しているのは、プログラム上のあるカタマリについて、その名前と実態が乖離していて、それがソフトウェアの「可管理性」の品質（手に負える状況である）を損ねている状況 なのです。そしてそのような状況は、母国語でプログラミングを行うことで、かなり改善されるのではないか、と考えているのです。
私は、インドのプログラマはインドの言語で、タイのプログラマはタイの言語で、日本のプログラマは日本の言語で、プログラムを記述することが、アメリカ シリコンバレーのひとり勝ちに対する小さな反論になり、ソフトウェア文化のさらなる発展、あるいは世界の"グローカル化"(→wikipedia) のきっかけになるのではないかと考えています。
英語以外ではコンパイラがまともに動かなかった10年前なら、日本語の識別子を用いる、なんていう案は、職場の上司のゲンコツ一発で却下されてしまう意見だったと思います。しかし、状況は日々変わっています。
日本人は日本語でコーディングしようぜ。まずは小さなところから。
ソフトウェアを設計・製造するという作業は、そのほとんどが、「概念に名前をつけて、コトバ（仕様書、設計書）に定着させる」作業です。
よいソフトウェアとは、利用者の要求を満たすのみでなく、その設計においても優れているものです。概念や構造が整頓されていることにより、より高い抽象度で概観することができる、可読性・可変更性が高い、そして可管理性が高いものです。しかし私たちは往々にして、よくないソフトウェアをつくってしまいます。
ソフトウェア上の概念に「適切な名前をつける」ことで、多くの問題が解決します。適切な名前をつけるには、プログラミング言語以前に人間が話す言語のセンスが必要だと思います。私たち末端の開発者が、より高いセンスを持っているのは、英語なのでしょうか、母国語なのでしょうか。
昨今、社内の公用語を英語にする、等の先鋭的な試みをされているIT企業もあると思いますが、それは日本の一部を構成する日本の企業として、日本人の雇用に貢献するのでしょうか。そして、日本の社会の豊かさに貢献するのでしょうか。
私は視野の狭い井の中の蛙かもしれません。しかし私は、ベターな道を探したいのです。
25年以上前の話ですが、あるNHKの番組がありました。案内役として坂村健先生が登場し、当時のコンピュータの状況を説明し、未来のコンピュータの姿を模索する内容でした。
番組の中で坂村健先生は、「人間がコンピュータの言語を学ぶのではなく、コンピュータが全ての人間の言語を学ぶべきだ」とおっしゃいました。
人間がコンピュータを操り、人間の世界を豊かなものにするのか、あるいはコンピュータが人間を操るのか。コンピュータは媒体であって、通信の両端には人間と人間がいます。そのことを坂村先生は強く訴えていたように思います。
坂村先生。先生はその後「超漢字」を開発されたり、コンピュータが扱う文字がユニコード化していく流れの中で、字体の細かな違いが淘汰されてしまうことに対する、文化的な観点からの懸念を発信されていたように解釈しています。25年経って、世界はどうなったでしょうか。貿易はますます盛んになり、情報の往き来も増えましたが、まだ国境はなくなっていませんし、コンピュータが全ての言語を学ぶにも至っていません。それでも、UTF-8には皆が納得できる妥協案としての光明があり、そろそろ成果を収穫できる季節に来ているように思います。
私は日本語コーディングが大好きですが、共通語としての英語の有用性については私も否定しません。
FastDBという、ロシアの方が作成されたオブジェクトDBMSを利用させていただいて、マニュアルの一部を日本語に翻訳させていただいたものをこのサイトで公開していますが、もしFastDBがロシア語で書かれていたら、私にはお手上げでした。英語で書かれていたからこそ、読むことができたのです。
Linuxの開発がフィンランドの言語だけで行われていたら、今のように花開いてはいなかったことでしょうし、私自身もLinuxからの多大な恩恵を、受けることができなかったと思います。
また、日本語で概念を整理した後、英語の識別子を考えるときに、より適切な言葉を思いつくのもよくある話です。複数の言語で考えることで、より一般的な概念に発想が着地することもあるでしょう。
さらに、自分が書いた文書を英語に翻訳することを経験することで、分かりやすい日本語で書くことを心がけるようになる、という作用もあります。
私が問題視しているのは、プログラム上のあるカタマリについて、その名前と実態が乖離していて、それがソフトウェアの「可管理性」の品質（手に負える状況である）を損ねている状況 なのです。そしてそのような状況は、母国語でプログラミングを行うことで、かなり改善されるのではないか、と考えているのです。
私は、インドのプログラマはインドの言語で、タイのプログラマはタイの言語で、日本のプログラマは日本の言語で、プログラムを記述することが、アメリカ シリコンバレーのひとり勝ちに対する小さな反論になり、ソフトウェア文化のさらなる発展、あるいは世界の"グローカル化"(→wikipedia) のきっかけになるのではないかと考えています。
英語以外ではコンパイラがまともに動かなかった10年前なら、日本語の識別子を用いる、なんていう案は、職場の上司のゲンコツ一発で却下されてしまう意見だったと思います。しかし、状況は日々変わっています。
日本人は日本語でコーディングしようぜ。まずは小さなところから。
追記: 2012年1月
マイクロソフト日本法人元社長、成毛眞さんが、面白い主張をされているようです。
『日本人の９割に英語はいらない』と。
Amazonでの批評にも参考になる記述が多く、ふむふむと思いましたが、9割に不要、とは1割の人には必要ということでもあります。
| リンク | 備考 |
|---|---|
| マイクロソフト元社長が“英語社内公用語化”を批判 | excite |
| Amazon: 日本人の９割に英語はいらない |
追記: 2012年10月
以下、別ページを内包: memo/20121027
おかしなエラーメッセージ
仕事で、また「おかしな英語風の言語」にイライラ。いい加減にしてくれ、通じる言語で書いてくれよと思う。
その意味不明なエラーメッセージは、誰に何を伝えようとしてるんだゴルァ
おかしなルーチン名
ルーチンの名前もおかしい。（今、誤変換で ルー珍名 と出て思わずワロタ）プログラミングのパラダイムは時代とともに発展し、転換していきます。
けども。ある時代で止まってるプログラム設計会社があるんですよ。おそらくたくさん。
日本語で設計書を書くとき、ルーチンやメソッドに体言止め風の名前つけるの、いい加減に止めようよ。
「設定ファイル読み込み」とか。
「設定ファイルチェック」とか。
和名でそういう、80年代みたいな、構造化プログラミング全盛時代みたいな処理名つけてるから、英名を
ConfigFileRead
ConfigFileCheck
とかつけちゃう子が出る。そりゃそうだろ。
そんで、ベテランもそれをレビューで指摘・修正できない。
英名を
ReadConfigFile
CheckConfigFile
てつけるんだったら、和名も
処理名：[設定ファイルを読む]
処理名：[設定ファイルをチェックする]
てつけなきゃダメなのよ。（する までつけるのが大事）
ありえないと思った？ なんで？ あなたが感じる違和感を、明確に説明できますか？
その違和感を、英語圏のひとたちは90年代にはもう飛び越えたんだよ。
今は00年代もすぎて10年代だってのに。
この、{プログラミング|自然}言語の感覚わかりますかね？
家を建てるならまず土地を平らにするでしょ
自分の母語を通じて言語そのものを考えられない人が、プログラム言語という記号言語を使って働いているのは滑稽だ。ソースと同じ内容を書いて（書きすぎて）ハマってる設計書。
ソースを読めない人が見る設計書を書くことに、何の意味があるのだろう。
マシン語で作るならまだしも、高級言語だよ？
人間が普通に仕様をざっと見ることができるレベルのソースと、細かいプログラミングロジックを書くソースとでレイヤを書き分けできるだろ。そうすりゃソースと二重管理のフローチャートなんて、書かないで済むんだよ。
できないのは、プログラミング言語の問題じゃなくて、書き手の言語感覚に問題があるんだよ。
名前づけが悪いのは、病状の中でも本当にたちが悪い。
おかしな名付けでプログラムを作るのは、歪んだ土地を平らにしないで家を建てる事のように見える。
あるいは、とのこやサーフェーサーを吹かないで荒い面に塗料を塗っているような。
プログラミング言語の前に、自然言語で箇条書きする研修をやらないと、まっすぐの家を作れないんじゃないのかね。
追記: 2013年1月
以下、別ページを内包:
+ 日本語コーディング・各言語で
日本語識別子を用いたコーディングができる、できないのメモ。
| プログラミング言語 | 日本語識別子の可否 | コメント |
|---|---|---|
| Java | 可能 | この文脈のパイオニアで、昔からできる。昔はUTF-16だったけど今はUTF-8。なお私はJava大嫌いです |
| PHP | 可能 | |
| Python3 | 可能 | |
| Python(2) | 不可能 | Python3に移行しようぜ |
| Ruby | 可能 | #! ruby -Ku でUTF-8N |
| C# | 可能 | |
| C/C++言語(WindowsVC++) | 可能 | 規格適合かは不明。だけど、今後使えなくなることはまずないだろう |
| C/C++言語(GCC) | 工夫により規格適合な方法で可能 | GCCで日本語識別子を使う - きじねこ |
| javascript | 可能 | |
| VB系 | 可能 |
追記: 2013年11月
以下、別ページを内包:
memo/20131112
日本語コーディング、日本語の識別子をプログラミングで用いるという話で、
「日本語コーディング」でググるとトップにこのページが出るのだけど、
「日本語プログラミング」では箸にも棒にもかからない。
うーむ。
この話題でよいスライドがありましたのでメモします。
【* 日々のメモ】
「日本語コーディング」でググるとトップにこのページが出るのだけど、
「日本語プログラミング」では箸にも棒にもかからない。
うーむ。
この話題でよいスライドがありましたのでメモします。
| リンク | 備考 |
|---|---|
| 日本語識別子の必要性 | slideshare |
【* 日々のメモ】