読みやすいプログラムを書くというモチベーション

最近ふと思った。

もしかしたら今の自分にとってプログラムを書くという事について、全くモチベーションが無いのではないか?

 

実際のところ、ここ最近は仕事の上では全くコードを書く仕事をしていないし、ましてやプライベートで書くこともほとんど無い。

一昔前には、寝ても覚めてもコード書く(or デバッグする)ことしか考えていなかったり、プログラマであるという誇りみたいな物を抱えていた気がするにもかかわらず...。

 

そんな訳で、ちょっと振り返る意味も込めて適当にエントリ書いてみる。

想定するシチュエーションは、電話とかでソースコードを見ながら他人に説明する場合。

普通にプログラムとかデバッグしてる場合に、そういうシチュエーションになることは少ないので、ソースコードを'''声に出して読み上げる'''というシチュエーションを想定している人ってほとんど居ない。

 

業種にもよるのだけど、僕の場合は、実機がマシン室でしか触れないけど現地でソースコードを見れないみたいな状況とかで、そういう事が度々あって意識する様になっていた。

 

実は Togetter - 「新人プログラマへのアドバイス」 見てふと思った事なのだけど、「読みやすい」ソースコードという観点ってわかりやすいんじゃないかなと。実践するのもお手軽だし。

 

例えばこんなソースコード。

if (current_state == STATE_IDLE) ...

"if current state equal idle, then ..." と英語風に読み上げることが出来たりする。

そして、だいたい読み上げられる物はわかりやすい。

 

while (!found) ...  
while (found != true) ...

これも "while not found" の方が "while found is not true" と冗長に書かれるよりも読み上げやすいし、わかりやすく見える。

if (cs->state() == TIME_WAIT) ...  
if (cliant_sock->state() == TIME_WAIT) ...

この辺りを意識すると、自然と変数名なども読み上げやすくすることを意識するようになる。

 

"しーえす state equal TIME_WAIT"だと"しーえす"って何?とか思うけど"cliant sock"なら意味がわかりやすいので、無駄な省略をしなくなるとか、そういう副産物もある気がする。

コーディングルールでハンガリアンにしなきゃ!という場合があれば(僕は実際にハンガリアンのコーディングルールに遭遇したことは無いんだけど)、まぁ、そういう場合は単に「お約束」として気にしなければいい。

 

if (nCounter) ...
if (nCounter != 0) ...

逆に、こういうパターンだと、わかりやすかったりする利点があるっていう主張はたしかにそう(整数値を比較なしで条件文に入れるな、と)。読み上げるという観点で考えても"if nCounter then..." は流石に言葉が足りてない。"if nCounte is not 0 then..." にするとすっきりする。

 

とはいえ、無駄に頭をひねるよりもCODE COMPLETEとか読んで素直に受け取れば改善される、、、というレベルの話の様な気もするw

まぁ、こういう観点でも楽しいよね、というだけの小話。

 

エントリ書いてても楽しいのだけど、実際にやるより四方山話を考えているのが楽しいという...

正直なところ開発現場で後輩とかに教えていた頃に説明出来てればよかったなあという自戒もあるのだけど。