2018-08-09

量子論と霊の世界

「霊の世界を信じますか?」


うさんくささが先に立つこの問いは、実際とても曖昧でいろんな意味を含んでいるし、霊感商法といった闇の世界から、宗教や死者への尊厳の問題まで広く及ぶので、簡単に答えなど出せるはずはないだろう。

理化学系に属する人たちの中には、即座に非科学的であることを理由に否定する人がいる。
科学で解明できないことは全て否定するといった低次元な理由が大半だろうが、中にはあと何年もすれば人間が存在する理由も全て科学的に証明できると豪語するどこぞの大学の教授のような人物もいる。火の玉をプラズマで再現して見せて、調子に乗ってしまったのだろうか?(テレビのバラエティ番組内での発言を真に受けることもないとは思うが)

ヒッグス粒子の存在が証明された頃、それをきっかけに素人向けの量子論や量子力学の本を何冊か読んでみた。とても楽しかった。
それまでも、光が波の性質と粒子の性質を併せ持っているだとか、アインシュタインが量子論に反発するも、相対性理論の次に、それを度台にして発展した物理学なのだろう、ということは何となく知っていた。

素人向けの量子力学の説明では数学を使うことができない。そのため、比喩に頼る傾向があり、そしてそれが必ずしも適切でない場合も多々あるようだ。しかし、数学を使わず、僕のような素人にもその本質を伝えようとする本もあった。
そんな本に助けられて、量子論のおもしろいところだけをかいつまんで楽しませてもらったと思う。

そんな浅い理解でも、自分なりに考え、気が付くこともある。

たとえば、有名な「シュレーディンガーの猫」という思考実験があるが、僕はこの思考実験の本質とは別に、観測が観測対象に及ぼす影響について思い当たった。
通常、物理の実験では観測そのものが対象(結果)に影響を及ぼさないといった前提がある。
ニュートン物理学までの実験では、厳密には影響を及ぼしたとしても、それが無視できる程小さいので問題はなかった。
しかし、相手が量子になると、影響の度合いが100%、あるいはそれを超えてしまう。なので、非破壊検査はできないと言っていい。
(見る為に光を当てれば、対象がその光により変化してしまうといったようなこと)

つまり、観測を行うことそのものが、実はもっと本質的な「何か」なのではないか、という考えに行き着いたのだ。飛んでいる蚊を観測するためには、必ず叩き潰さなければならない世界なのだと。

これは、観測=対象に変化を加える、ということ。「シュレーディンガーの猫」も、猫の入った箱を開けたときに死んでいる、あるいは生きているの2択なのだが、開けない限りは死んでいるとも生きているとも言えない、という状況なのだ。いや、実際には死んでいる、とか、実際には生きているがその情報が伝わっていないだけだ、というのとは違う。箱を開けた瞬間に決定するという思考実験だ。つまり、箱を開けるまでは、猫は死んだ状態でもあり、生きた状態でもある、ということらしい。
しかし、実はこの話には何の矛盾もなく、箱を開けることによって猫に影響を与える、ということが本質なのではないか、と考える。観測が対象に影響を与える、ということを理論に取り入れるべきではないのか、ということだ。実際、どのような観測方法をとったとしても、素粒子を対象とした場合、それに影響を与えてしまうことは、おそらく数学を使って証明できることなのではないか、と思うからだ。

非常に観念的で現実味の無い話に思えるかも知れないが、物の最小単位である素粒子はそんな世界なのだ。

この、観測が対象に与える影響という点については、まだまだ考慮すべき点があると思う。ただ、思考実験のように観測自体が無影響であるという前提自体が無意味ではないのかな、ということが言いたいのだ。
ただ、物理学者はこんなことは当然すぎて問題にしていない可能性の方が高いとも思う。

そして、もっと抽象的で漠然とした考えにも行き着いた。今の量子力学、量子論はまだ完成していない、発展途上であることは誰もが認めるところではあるが、現時点でこの理論は非常に複雑、いや、必要以上に複雑すぎるという点だ。まるで、天動説を元にして天体の動きを説明しているかのようだ、と感じたのだ。あまりに、例外が多すぎる気がする。一本筋の通った、美しい理論とはほど遠い。
天動説では複雑怪奇だった天体の動きは、地動説の発見でとてもシンプルになった。

量子論は、まだ天動説でしか説明できていないように思えるのだ。ひょっとすると、数ある理論の中には、地動説に限りなく接近しているものもあるのかも知れないが、まだそこには至っていないというのが現実であろう。

天動説から地動説への革命的変化のようなことが、量子論にも起こらなければ、現在謎とされている事の全てを説明できる日は来ないかも知れない。しかし、ひょっとするとそれは人間には永遠に解けない問題かも知れないが。


そんな謎が解明されれば、ひょっとすると宇宙の存在理由も判るのかも知れない。そしてその頃になれば、霊であるとか、魂の存在であるとか、必然的に解明されている可能性もある。

そんな考えの1つのきっかけは、「量子のもつれ」という現象だ。説明は省くが、この現象では情報が光の速度を超える。距離には関係なく、瞬時に伝わるというものだ。現象は知られていても、理屈は解明されていない。

たとえば、これは無いとは思うのだが、人間などの脳がこの現象を利用して情報伝達が可能だったとすれば、テレパシーが従来の電磁波などによるものと想定した観測方法で感知できなくても当然なのだ。まぁ、これはいかにも素人が考えつきそうな話ではある。

しかし、目に見えるものしか信じようとしない現実論者が見ているものは、いったい何なのだろうか、という考えに飛躍した。彼らは量子論を知らないし、知ったとしても宗教のように単なる絵空事のようにしか感じ取ることしかできないのかも知れない。
しかし、この世界の大元は、そのような人間にとって観念的でさえある物理世界によって成り立っているのは、現実なのだ。

そうした物理的な世界において、宇宙の存在理由でさえまだ何も判っていないのに、増して、人間の存在の、その奇跡の度合いは計り知れないものがあるということなのだ。つまり、我々が見ている現実は、奇跡の中の奇跡なのだ。人間が存在するのだから、霊の存在が現実的だとか、非現実的だといった議論はほぼ無意味に思えるのだ。
何の意思もなく、自然に、勝手に人間が存在することなど、僕には全く考えられない。
人間はそれを神と呼ぶのだろうが、それは量子論をはじめとする物理学の延長にあるものののはずだ。

その宗教ではない神が、人に隠し事をしていて、しかしそれが隠しきれない何か、それが霊的な現象として認知されているのかも知れないと思う。

霊的な体験


奇跡と偶然は相反することではない。

たとえば、ある夜に急に亡くなった人が、昼間現れた虹を見舞客と一緒に見た。その虹を見て、「親類の葬儀の帰途にも虹が出て、あれを渡っていったのね」、という話をし合った事を思い出し、見舞客にその事を伝えていた。

この昼間の虹は、単なる偶然だろうか。あるいは、奇跡なのだろうか。

虹を見た夜に亡くなった人の事を知らなければ、偶然ですらない。知っていたとしても、見舞客なら奇跡だと感慨をもつだろうし、他人の感情に寄り添えない立場ならただの偶然で片付ける。見方の違いだ。

仮に、昼間の虹を見せたのが霊的な人間以外の意思だったとする。であれば、その「意思」は偶然を装い、数学的に、物理的に矛盾がないようにうまく装って虹を発生させるに違いない。

だから、偶然と奇跡は見方によって違うだけだ。光が、粒子の性質と波の性質という、相反する性質を併せ持っているのと少し似ている。


実は、上記の虹を見た夜に亡くなったのは僕の母であり、見舞客は僕と母の友人だった。

亡くなった後も、母の事で親類で集まりがあったとき、天気はずっと雨だったのに、みんなが目的地で車を降りる頃には雨が止み、建物の中にいるときは雨になり、また車に戻る時間になったらまた止んだ。雨はけっこう激しかったから、傘を差さずに済んだのは助かった。
母は医大に検体をしていて、3年を過ぎて火葬になった日も、その前後はずっとずっと雨続きだったのに、その日だけ晴れた。その日ももちろん親類や友人など母の縁者が集まった。

この天候に関しては、僕には単なる偶然には思えない。


夢の話もある。昔、世話になっていたクラシックギターの先生の夢を、ある日唐突に見た。何のきっかけもなかったし、最後にお会いしてから30年は経っていて、とても気になってしまい、ネットでいろいろ探してみたが情報は得られなかった。1年位して、またその先生の夢を見て、またネットで検索すると、最初に夢を見た一週間前くらいに亡くなっていたことが判明した。49日が過ぎるまでは亡くなったことは公表されていなかったらしい。このことは日記を付けていたので、はっきりとしている。

他にも、親戚が亡くなって、やはり一週間以内くらいにその人の夢を見たこともあった。

天候などとは違い、夢という曖昧ではあるが、その人個人だけに係わる現象だから、あちらの意思が伝える手段としては簡単なのかも知れない。

宗教


偶然は、見る人や立場によって奇跡になる。同じように、人間にとって不可解であったり、科学的に説明できない現象も奇跡だったり、神の御業だとか、祟りだとか解釈される。
宗教の多くは、その解釈を人間の想像力で膨らませたものだと言っていいと思う。信じる人にとって、それは事実と同じなのかも知れない。

しかし、過剰な解釈は人間の都合や欲に利用される。人々をコントロールしたり、金儲けだったり。
だから、僕は大方の宗教に深く加担しないように気をつけている。

しかし、一方では、多くの人が何かを一心に信じることで、「何か」に影響を与える可能性を否定できないでいる。本当かどうかは僕は疑わしいと感じているが、量子の原理を使ったランダム数発生装置が、大勢の人の活動によって確率が偏った、という実験があるようだ。この実験の前提となる環境は客観性に乏しく、甚だ疑わしい部分もあると感じてはいるが、事実だとすれば非常に興味深い。
いずれにしても、人の精神的な活動が物理的な影響を生む可能性は否定できないと考えている。それが、宗教活動の一部において、リアリティーを持たせている可能性があるのではないか、と考え、僕は真面目に神社でお参りするようになった。
以前は、神道に対して胡散臭い占いと同レベルでしか向き合っていなかったように思うが。



まだまだ、漠然とした結びつけしかできてはいないが、量子論と霊は、案外近しい存在なのかも知れない、と考えている。


2018-03-18

PCが売れなくなった本当の理由

「開発環境」カテゴリーを追加し、最初の投稿です。

主な問題

PCが売れなくなったと聞きます。スマホにその役割の多くを奪われた結果と思われます。
しかし、PCそのものにもその一因があるようにも思えるのです。

今、個人的にWindowsのノートPCが欲しいと思っています。ノートPCは比較的高額で、昔から必要に迫られない限り買う事はありませんでした。普段は主に自作のデスクトップを使用しています。

それがいいのか悪いのか、あるいは先取りなのか、2in1という新たに発現したPCがあります。Windows 10の機能を最も活かすハードウェア、というか、Windows 10の為に作られたPCと言ってもいいのかも知れません。

残念ながら、僕自身は2in1PCを直接的に必要とはしていません。しかし、アプリケーションを作成するためには、全ての機能が使える環境を手元に置いて、実際に使い続ける必要があります。つまり、アプリケーションのターゲットとしての意味があるのです。

Appleは現時点で2in1PCを遠くから静観しているだけのように見えます。また、iOSとmacOSを統合することも実現できていません。

しかし、AppleとMicrosoftでは前提となる環境に違いがあります。AppleはモバイルOSとしてiOSは大成功を収めていますが、Microsoftは完敗状態でした。完敗したOSを捨てることに躊躇う必要は無かったはずです。そこで、主流であるWindowsにモバイルOSとしての機能をくっつけてしまったわけです。
対して、AppleはPC用もモバイル用も成功していますから、無理にくっつける必要はないのかも知れません。

Microsoftは世界で一番普及しているOSをモバイル対応とすることでスマートフォンなどの巻き返しを考えたのかも知れません。
しかし、MicrosoftはWindows 8で一度失敗しています。しかも、失敗をよく反省もせず、MicrosoftはWindows 10を世の中に押しつけてきました。特に、デスクトップPCを使っている人にとって何のメリットも無い、むしろ害悪となる非常に視認性の悪いデザインは今でも大変不評です。

では、2in1PCのように、タッチパネルを使ったPCでWindows 10は本領を発揮するのでしょうか。僕はまだ店で少し触っただけですが、とても水を得た魚というような印象を持つことはできませんでした。もちろん、タブレットモードも試してみました。
最も当てはまる言葉は「どっちつかず」、あるいは「中途半端」です。

そして、あらためて思うのは、タッチパネルに無縁な環境なのに、それがまるでタッチパネルのためのような見た目ののっぺらぼうで平面的なデザイン。そして、それは決してタッチパネルを通して使ってみても使いやすいわけでは無いという事実です。
Windows XP時代には1つのウインドウにいくつものカラーやサイズを設定できる項目がありました。Windows 7はそれがずいぶんと減りましたが、それでも完成度の高いデザインでほとんど不満はありませんでした。視認性が高く、凝ったデザインなのに湯水のごとく当たり前にストレス無く使うことができました。
それまで培ってきたデザインの集大成、研究の成果が盛り込まれた素晴らしいものだったと感じています。

しかし、Windows 8、10でMicrosoftはその長年の成果のほとんどを捨て去りました。画面を見ているだけで目が疲れます。特に、ファイルエクスプローラーはほとんど全体的に白っぽく見えるため、非常に大きなストレスを感じてしまいます。
非アクティブのウインドウのタイトルの背景が白に固定されているため、これも非常に鬱陶しく感じます。

Microsoftは頭がおかしくなったのでしょうか。いえ、頭を失ったのですね。しかも、失った頭自体は寄付という自己満足の偽善道楽に興じていて、胴体を顧みることはもう永遠にないのでしょう。
この企業は相変わらず巨大ですが、過去の信用という遺産を無駄遣いし、破壊しながら生き恥をさらしている衰退途上企業と言っていいのではないでしょうか。

このMicrosoftの体たらくでPCが以前より売れるようになるはずなど、あり得ないと思います。
スマホにユーザを取られたことを除き、PCが売れなくなった最も大きな原因は、Microsoftの体たらくにあると思うのです。

もう1つの大きな問題

そして、Microsoftの体たらくに同調するかのように、各社PCメーカーの体たらくもあるのです。
PCなのになぜか不便な方に向かっています。拡張性も放棄したようです。この点ではAppleも同罪ですね。
しかし、ハードウエアメーカーとしてのMicrosoftやApple以外のメーカーの最も共通する具体的な問題は、ノートPCの画面を概ね16:9に揃えてしまったことです。特に、13インチ台の小型PCを16:9にすると、縦のサイズがごく僅かとなってしまい、文章などの編集に非常に大きなストレスを感じてしまうのです。
そもそも、16:9はどこから来たのでしょうか。動画のハイビジョンサイズしか考えられませんが、これはPCのワークエリアとして全く適性がありません。
16:9のパネルは安く生産されるため、弱小のメーカーではこれを仕方なく使って安く上げて利益を確保している、と思っていました。しかし、実際にはわざわざ16:9にしているという情報を得ることがありました。だとしたら、なんと愚かなことでしょうか。

仕方なく13.3インチの16:9サイズのノートPCをしばらく使っていました。しかし、流石にメインで使うことはできませんでした。ネットサーフィンでさえ我慢を強いられます。
16:9の画面でPCを作るなど、非常に愚かなことだと感じていますが、バカがバカの真似をしてAppleとMicrosoft以外のほとんどのノートPCは16:9なのです。昔のように4:3にしろとは言いいませんが、13インチ台ならせめて3:2、15インチ台なら最悪でも16:10ではないでしょうか。

こんな不真面目なPCを真面目に使う気になれないのは、至極当然のことなのです。こんなクソPCを生産して売れなくなったと嘆いているバカどもに、本質に立ち返れと言いたいのです。

2018-02-14

身につけるべきプログラマの習慣 その7

本当の問題を探る

人は最初に入ってきた情報を優先しがちです。先入観もそういったことの1つです。
だから、何か問題が起こったとき、それを見たまま聞いたまま受け取ってしまいます。
更に悪いことに、問題の本質にたどり着けないまま我先にと夢中になって解決策を考案してしまうのです。

日常茶飯事の光景ではないでしょうか?

本当の問題は何か、一度咀嚼して考えなければなりません。
まずは、それが誰にとっての問題であるか、という点が大きなヒントになります。立場を変えれば、それは問題ではないかも知れません。誰かにとって問題でも、それが誰かにとってはメリットかも知れないのです。

そして、問題の本質を探るときに大切なことは、客観的視点です。問題の渦中にいる感覚でいるうちは、本質的な解決策を見出すことはできません。

そして、候補に挙げた解決策が、どの問題をどのように解決するのかを予測します。1つの問題を解決することで、別の新たな問題を発生させてしまうことにも注意を払います。
そのような副作用の問題を含め、一気に解決できることが理想かも知れません。そのような理想的な解決には、発想力、創造力、想像力が欠かせません。

創造力が大切

矛盾する要素を1つ高い次元で解決して融和させることは、創造的脳活動の本質だと考えています。
脳のこの能力を引き出させるためには、記憶依存の思考を行っていてはいけません。また、スケジュールなどに追われ、尻を叩かれながらの作業でも決して行えません。

精神的なゆとりや前向きの気持ちをもつことが大切ですが、それにはそういった環境が必須になります。
残念ながら、日本の企業の会社勤めではそういった環境はほとんど望むことはできません。日本人は記憶に頼る教育しか受けていないからかも知れません。

僕自身は長年在宅で、自分の体調と向き合いながらその能力を自分なりに引き出してきました。そのことで、大技、小技を繰り出してきました。もし、部屋に監視カメラが取り付けてあれば、そんな技を繰り出す前は、まるでサボっているように見えることでしょう。

発想力を必要としない、コツコツとした非創造的な作業においては、とにかく手を動かしなさい、という製造業的なやり方でも世界に通用していたかも知れませんが、ソフトウエア開発というのは、言わば創造的思考の連続でもあります。少なくとも、そういった作業フェーズの時だけは在宅での作業を認めるなど、創造性を引き出す環境作りに真剣に取り組まなければ、ますます日本の技術力は地に落ちていく一方になると思います。


2018-02-13

身につけるべきプログラマの習慣 その6

試験でのバグ出しは誉れ

バグ出しでたくさん発見されると成績を下げるという評価があります。これは最低です。
また、バグ出しなのに、自分のコードにバグが見つかるといちいちがっかりして落ち込む人を見かけますが、それもおかしいですね。

バグというのは、人間なのだから必ず入り込むものです。その率は人によって異なりますが、多かれ少なかれ必ず入り込むのです。

最終的にバグを取り去れば良くて、途中でのバグの件数自体は問題ではありません。

試験の局面においては極力バグを洗い出すことが重要で、次の行程に問題を残さないようにしなければならなりません。
だから、既にできたコードに対しては、極力バグを残さないようにできる限り多く発見することが誉れであって、恥ではないのです。


もちろん、バグにも質があります。単純なミスが原因なものもありますし、ロジックをよく理解しないまま当てずっぽうに書いたコードが動かない、という最低レベルのものまであります。
後者の場合、プログラマの資質にまで問題の範囲が及ぶことになります。動くはず、という確証のないままコーディング行程を終了させたのは深刻な問題かも知れませんね。
また、単純なミスであっても、あまり多発するようではデバッグを含め、余分に工数を要してしまうことにはなります。

プログラミング時にいかにバグを入れないようにするか、それもソフトウエア工学の1つです。そういったことをちゃんと守った上で発生するバグは、通常さほど深刻なものにはならないはずです。

もし、バグを恥じるのであれば、納品後に発生すること、あるいは、バグの量ではなく、悪質なバグに対してなのではないでしょうか。

笑い話?

30年位前の、大手企業での実話です。
バグの発生率は統計的に決まっているという点に着目し、ある人の出したバグがその範囲に収まっていない場合、試験を通過させないというものでした。
これはバグが多発した場合もそうですが、バグが少なすぎても試験をパスさせないのです。
そこで、あるグループのリーダーは、バグが少なすぎるプログラマに対して、わざとバグを入れ込めという命令を下しました。

プログラミングの本質を理解していない、あるいは、その内容を理解しないまま評価しようとすると、こういう馬鹿げたことになるのでしょうね。無能な管理者が前提の方法論なのです。

2018-02-11

身につけるべきプログラマの習慣 その5

表と裏を区別する

もしもこれが人間性の話だとしたら、もちろん裏表はない方がいいですよね?
でも、プログラミングにおいては、いつも表と裏をはっきりと区別しなければなりません。外面と、内面を意識すると言い換えてもいいです。

外面、それはインタフェースの部分に相当します。
アプリケーションの外面ならユーザインタフェースであったり、公開API等の仕様であったりしますね。これはしっかりと仕様を決めなければ話にならない部分でもあります。

ライブラリプログラムだった場合はどうでしょうか。
C言語のような関数だけでできているライブラリもあれば、C++のクラスライブラリのようなものもあります。
通常、こういったプログラムはインタフェース仕様書を書いてライブラリのユーザに提供する機能や動作、使用方法や手順をしっかりと定義します。
同じ機能を提供するのであれば、よりシンプルなインタフェースが求められます。

ところが、仲の良い同一プロジェクトチーム内でプログラムを分担するような場合、ついついそれを使う側も作る側も同じチームだから、内々で済ませてしまえるという甘えが出てしまいがちです。
インタフェース仕様をきっちり決めずに作り始めてしまったり、決めても作る時の身勝手な都合でそれを守らずにどんどん崩してしまうのです。
その結果、インタフェースの内側と外側の区別がなくなってしまい、ぐだぐだになってしまうのですね。これはプログラムの品質が格段に落ちることを意味しています。とても深刻な事態なのです。

もし、ぐだぐだになってしまっても誰にも見せない内々の話なんだから構わないだろう、と考えたあなたはかなりやばいです。

ライブラリに限らず、プログラムには使う側と作る側があります(一番外側のプログラムは使う側の立場のみとも言えますが、たとえばmain()関数はOSから使われると考えることもできます)。そこをしっかりと区別しましょう、ということですね。これはむしろ本能的な感覚として身につけておくべき基本的な習慣だと、僕は感じています。

プログラムを関数やクラスといった単位、あるいはもっと小さな単位かも知れませんが、そのまとまりごとに内側と外側を意識して作ることが大切です。

オブジェクト指向プログラムの醍醐味

オブジェクト指向プログラミングで、クラスのユーザ側から見える仕様を設計することはとても楽しいことです。単なる関数と違って、設計方法を工夫することで非常にスマートでセンスの良いクラスインタフェースを実現できるからです。言わば、外面を格好よくできるのですね。

1人の担当者がそのユーザにもなるし、制作者にもなることは普通のことですが、他の章でも書いたように、明日の自分は他人ですから、その他人に向けてよいプログラムを作る、という意識を持つことができるわけです。
そして、実際に明日そのプログラムを使ってみたときに感じる快感は、ある意味独りよがりなのかも知れませんが、それもプログラミングにおける醍醐味の1つだと考えています。


2018-02-10

身につけるべきプログラマの習慣 その4

全ての選択には理由がある

どんな些細なことでも、選択肢があればそこに優劣があります。
多くの場合、論理的に優劣の説明ができ、普遍的な選択というものが決まってきます。
そのことを無視して、何も考えずに自分独自の選択をするほど、その仕事の結果はチープになっていくのです。

もちろん、本質的な問題は個々の事情によって異なる場合も意外に多いと言えます。
問題の焦点の当て方によって、解決すべき問題が異なり、同じ選択肢であってもいつも正しい答えが1つとは限らないこともあります。

普遍的で絶対的な答えがあったとしても、それさえも揺るがすような事情が本当にあるかも知れません。そのことを理解していれば、闇雲に他人の書いたコードを尊大に否定することはできないはずです。


しかし、数々の問題を検討した結果ではなく、何も考えずにあなたの個人的な経験だけを全ての世界だと信じ、最初に見たたままの習慣を間違っていてもそのままにしておくことはみっともないばかりか、能力の低いエンジニアであると、密かに、しかし確実に評価されてしまいます。
増して、その理由に自分のセンスだとか、美学だとかを持ち出しようものなら、挽回できないほどに信用は失墜します。

どちらでもいいということは、特にこのICTの世界ではほぼあり得ません。しかし、それを知った上、理解した上で妥協をした方がいいことも多々ありますので、そこは誤解のないように。

事例

C言語系のプログラミングソース、中括弧「{}」の始まりをどこに書きますか。
これは、始まりと終りの括弧を同じインデントカラム位置に書くのが正解です。しかし、中括弧の始まりをその上にあるifだとかwhileだとかと同じ行の一番後ろに書く人が多いですね。これは、昔々、大昔、ソースコード印刷時の行数を減らすための習慣があった頃にできたC言語の教科書の書き方に習っている人が多いことが原因だと思われます。
多くの人が正しさよりも最初に見たすりこみに支配されているのです。

僕自身も、C言語を始めて5年位は、なんとなく疑問に感じながらもそのようなスタイルで書いていました。しかし、ある日ある開発環境でソースコード整形ツールを使ってみると、全て始まりの中括弧はカラム位置を揃えられてしまいました。最初は戸惑いましたが、その書き方の方がつまらないバグやミスを減らせることを実感できたので、以来その描き方を貫いています。(同じ行で中括弧を閉じる場合は別です)

その選択の理由は体験そのものではありません。体験を元にした普遍的な理屈です。
それは・・・

人は図形を素早く感覚的に認識する能力があります。
中括弧の始まりと終りが同じインデントのカラム位置に存在することで、図形的に囲まれていることを直感的に認識することができるのです。そのことで、コードの視認性が格段に高まります。
一般の文章でも、罫線に囲まれていると直感的にそこがまとまっていることを認識しやすいでしょ?(日本人は特に好きなはず)
それと一緒です。

逆に、他の某言語のように begin と end という単語で囲まれているとあまり直感的に見ることができなくなり、視認性が悪くなりますね。
同様に、中括弧の位置がずれていれば、結局その分余計な情報処理が脳で起こってしまうので、始まりと終りの位置を揃えたコードに比べてやや視認性に劣ってしまいます。

せっかくC系の言語は図形的な表現をして視認性を高めるデザインになっているのに、わざわざそのメリットを削ぐことは正しくないと断言できます。

ですが、長年そのスタイルで書いてきたプログラマに文句は言いません。スタイルが統一されていれば、そこまで読み辛いということもありませんし。
でも、一番正しい正解というわけでもありません。
改善する力が残っているならば、よりよい選択をすべきです。


身につけるべきプログラマの習慣 その3

明日の自分は他人と思う

プログラマであれば、特にコメントに気を遣いましょう。コメントは後で書くのではなく、コードと同時に書かなければいけません。明日どころか、10分後にはなぜそのようなコードを書いたのか判らなくなることさえあるからです。

しかし、プログラミングでコメントに依存したコードを書くのは完全にNGです。コメントの内容は必ずしも信用できないからです。特に、修正を繰り返したコードは、コメントがメンテナンスされていないことが多々あります。
なので、第一義的にはコメントを読まなくても理解しやすいコードを目指します。
そして、コメントはコード自体では何をしているか判りにくい箇所を捕捉し、コードの可読性を高めることを目的とします。

このようにすることで、多大な複雑系で疲弊し、記憶することを放棄した脳にも優しくなり、明日他人になった自分を取り戻すことができるようになります。

そして、それは本当の他人に対しても優しくなり、保守性、つまりソフトウエア制作における「質」の要素の1つ、を改善することができるのです。


自分を含めた他人に対して優しく作ること、それは善意のあるソフトウエア制作であり、技術者の善意、という最近では忘れられてしまった大切な精神を思い出させる行為でもありますね。

これなくして、技術者は成立しない「何か」の1つなのではないでしょうか。