2008年11月25日(火)

サンプルコードで語る難しさ

テーマ:コーディング

プログラミング入門者のための教材として、「カレンダーを表示するプログラムを作れ」という課題がある。この課題に対して「カレンダーなんて OS に付属しているのに、なんでそんなもの作るんですか?」という人がいる。なんという的外れな意見だろう。言うまでもなく、勉強のために作るのであって、使いたいから作るわけではない。


これは極端な例だが、この手の齟齬はよく起こる。ブログのコメントなどを読んでいると、「本来の意図が伝わっていないな」と思うことは日常茶飯事である。



CodeZine の「コーディングスタイルの常識をぶち壊せ 」という記事のコメントや「はてブ」のコメントを読んでいて、改めて感じた。


この記事の2つ目のサンプルソースについて、「こんな用途に switch は使うべきでない」とか、「配列を使ったほうがよい」などというのは野暮である。「常識」的に考えて、この記事の著者も他の読者もそんなことは分かっているだろう。


ここでは、「同種の記述を繰り返す時は、複数行にせず、桁位置を揃えて書くと見やすい」と言っているだけである(つまり「表」のようなコードにしろと)。サンプルソースでは、その「同種の記述」の単純な例として、たまたま「2つの文字列リテラルの変数への代入文」が書かれているというだけである。もちろん、代入文である必要はなく、数値演算でも関数呼び出しでも、何でもよかったはずだ。


しかし、この何でもいいはずの処理内容(ここでは代入文)に引きずられてしまう読者は意外と多い。プログラマがソースコードを読むということは、普通なら「処理内容を理解する」ということなので、そういう読み方が染みついてしまうのだろう。「ソースはこう読むものだ」という「常識」にとらわれて読み方を変えることができないとも言える。


そういう意味で、「処理内容以外のことを伝える」ためのサンプルソースを作ることは難しい。



このブログでも、「コードの書き方」を論ずるためにサンプルソースを載せることがあるが、文章を書く以上に頭を悩ませる。「書き方」を見せるだけだから「処理内容」は何でもよい、といっても、リアリティがなければ上記のように読者の気が逸れてしまう。実例(職場で見つけたコード)を載せればリアルではあるが、逆に複雑になりすぎて論点がぼやけたり、一部だけ抜き出しても意味不明になったりする。


実は、上記の CodeZine の記事と似た内容の記事も書いたことがある。「あなたにもできること 」がそれだ。配列を使った簡単なサンプルソースを載せているだけだが、実はかなり悩んだ結果である。今読み返すと、あまりに説明が短いため、意図が伝わっていないような気もするので、ついでに補足しておこう。


コーディングの際、同じような処理を繰り返して書くときには、上に書いた行をコピーして下の行を作り、少しだけ改変していくような書き方をすることが多いと思う。が、そこで、改変し忘れるというミスをしたことはないだろうか? この手のミスを防ぐには、どうすればよいだろうか?


最低限必要なことは、自分で書いたソースコードを読み返してチェックすることである。その時、「修正箇所」の桁位置が揃っていた方が、ガタガタと不揃いであるよりもずっとチェックしやすい。視線を縦に真っ直ぐ流せるからだ。


コードを印刷してチェックする場合は、指でなぞったり、ペンで印もつけやすい。画面でチェックする場合でも、カーソル(キャレット)を同じ桁位置で縦に動かして記述を追えるので確認しやすい。少なくとも私は、何度もそういう経験をしているので、自然とソースコードの桁を揃えるようになった。



このようなソース・チェック時のメリットは、CodeZine の記事で「ケアレスBUGの混入が防げるため、メンテナンス性が上が」ると書かれていることと同じだろう。CodeZine の記事では、「桁位置を揃える」というだけでなく、「複数行にまたがらせない」という点も例示されているという意味では、よい記事だと思う。


しかし、「メリット」の説明がこれだけでは不足だ。「そんなことは誰もが承知している」という前提で書かれているのだろう。つまり、プログラマの「常識」だと。しかし、ソースを読み返さないプログラマは、意外と多い(記述ミスは動作確認でも見つけられるので)。常識と思っていることも、本当は常識ではないのかもしれない。そういう意味でも、「常識をぶち壊す」ということは難しいものである。







■関連記事
あなたにもできること
誰のためのコード?
まずは丁寧なプログラミングを
プログラムは二度書け
読者指向プログラミング




プログラマの完全常識 開発者が知っておくべきプロの知恵
矢沢 久雄
技術評論社
売り上げランキング: 175375
おすすめ度の平均: 4.5
5 コンピューターを舞台裏から見よう
4 ソフトウェア業界で働く事を考えている人は読んでおいた方が良い。情報処理技術者試験対策としても。
4 プログラマ入門用本です。
5 プログラマの完全常識


Code Reading―オープンソースから学ぶソフトウェア開発技法
トップスタジオ まつもと ゆきひろ 平林 俊一 鵜飼 文敏
毎日コミュニケーションズ
売り上げランキング: 14938
おすすめ度の平均: 4.0
4 コードリーディングのイロハ&必要な知識・技術の全装備
5 Code completeと併せて読むとよい
4 着眼点は良いと思う
3 意外なほどに教科書的な内容
4 ホップ・ステップ・ジャンプ
AD
いいね!した人  |  コメント(16)  |  リブログ(0)

argvさんの読者になろう

ブログの更新情報が受け取れて、アクセスが簡単になります

コメント

[コメントをする]

16 ■Re:紙でのコードチェック Re:無題

そんな開発現場において、「普通にコーディングしていれば、そんなことには
ならないでしょ?」 なんていうアドバイスなんては、何の意味もないのです。
今そこに、「普通じゃないコード」があるんですから。

「普通でないプログラマ」がどんどん湧いて来て、膨大な行の「普通でないコード」
を生み出し、それらが我が物顔で「動作実績」を作り、「普通のプログラマ」に
保守を迫ってくるんですから。

保守を任された奴は「なんでこんな書き方してやがるんだ!」と悪態をつきつつも、
黙々とコードを紐解いていくしかない。

というわけで、「普通でないプログラマ」に、せめて「体裁」だけでも読みやすく
して欲しい(それぐらいのスキルはあって欲しい)、と思って書いたのが、
「あなたにもできること」であり、本記事の後半はその補足です。

そして、このブログは、「普通でないプログラマ」に少しでもコードの「読みやすさ」
について考えてほしい、という思いで書いている記事が多いのです。

なので、Anonymous さんのようにスキルのある方にとっては、「何を低レベルな話を」
と思われることも多いかもしれませんが、そういう背景をご理解いただければと
思います。

15 ■紙でのコードチェック Re:無題

Anonymous さん、

> >コードを印刷してチェックする
> というのは噴飯物ですね。

紙でのチェックを馬鹿にされているのなら、理由を教えてください。

画面でのチェックと紙でのチェック、それぞれに利点があると思います。

私が考える、紙の大きなメリットは、スクロールなどで見切れることがないので
「画面よりも見通しがよい」こと、そして、何より「自由に書き込みができること」
です。

特に、他人の書いた長くてぐちゃぐちゃしたコードを初めて読む時には、紙に
頼らざるを得ないことがあります。

経験がなければご理解いただけないかもしれませんが、残念ながら、私の周り
には、印刷したコードにペンでマークやら矢印やらを書き込んで行かないと、
とても追いかけられないようなコードがゴロゴロしています。

長いソースファイルの何百分の1しか同時に見えない画面。つい今したが上に
スクロールアウトしたはずのコードがまた下から出てくる。いや、よく見ると
違うコードなのか? まてよ、こっちのファイルにも同じようなコードが?
あれ、今どこ見ていたんだっけ? ええい、面倒だ、印刷しちまえ!
と、自然になるわけです。

単に私の読解力が低いだけと言われるかもしれませんが、他の人の意見を聞く
限り、そうでもないはずです。

また、私の会社のスキルの問題というだけでなく、協力会社さんが書いたものや、
他社から引き継いだコードにも、少なからずそういうものがあるので、業界全体に
言えることだと思っています。

本記事の「桁揃え」の話も同じで、「うねるように」大量のリテラルを並べて
いるソースなんてザラにあるわけです。そうすると、体裁だけでも編集して、
少しでも読めるようにと、手が勝手に動くというか、もう、そうせずにいられ
ないんですね。

14 ■Re:無題

Anonymous さん、

> だからこそ、「そうでない」と言いたいならば、替えが効かないような例を出さなければいけないわけです。

その通りだと思います。

そして、「そういう例を出すのは、思ったより難しいぞ」ということが言いたくて
この「サンプルコードで語る難しさ」というエントリを書いているわけです。

この「桁揃え」の例を「替えが効かない」方向に考えていくと、配列の初期化だったり、
ポリモーフィズム下のクラス定義だったり、あるいは、外だしのデータ見たいな形に
なっていくと思います。そして、例としてソースコードの形で載せるなら、やはり、
配列の初期化が妥当だろうと思います。そこで、本文でリンクしている別エントリ
「あなたにもできること」では、そのような例を挙げています。

…が、今見返すと、この例は、そこだけ見ても値の意味がわからないですね。
もっといい例はいくらでも作れそうですけど、9年前の私にはこれが精一杯
だったんでしょう…。

13 ■Re:Re:無題


> 「ソフトを作る」ことと「プログラムを書く(プログラミング言語を学ぶ)」ことは異なる。初心者はいきなりゲームを作ろうとして挫折することが多い。

ついでに、こちらの論点でお答えしますと、Anonymous さんの主張とは逆に
なるかもしれませんが、私なら、
「教材に取り組むのなんてやめて、ゲームでも何でも、作りたいものを作るべき」
と言います。まずは、なによりモチベーションが重要だと思うので。

よろしければ、こちらもどうぞ。
http://ameblo.jp/argv/entry-10036422006.html

12 ■Re:無題

Anonymous さん

オワコンかもしれないブログへの興味深いコメント、ありがとうございます。

論点がずれていることを承知の上で突っ込まれているようなので、返答に
困りますが、普通に返します。

記事の冒頭の話は「教材」が「課題」として提示された状況下です。
したがって、「学習すること」が目的であることは自明です。
にもかかわらず、「物を作ること」が目的であるかのような誤解をしている、
ということを「的外れ」と表現しています。

要するに、「空気が読めていない」ということです。こういう人は、
プログラミング以前に、色々なコミュニケーションで問題になります。

読者層を考えて、身近なプログラミング入門時の出来事を例にして
いますが、そこは話の本質ではありません。

しかし、「例が身近であるせいで、誤読が発生しやすくなる」という現象こそ、
まさに、この記事で指摘しているところなのですが、それがこの記事自身と
Anonymous さんとの間で発生するとは、なんという皮肉!

11 ■無題

それで、

>ここでは、「同種の記述を繰り返す時は、複数行にせず、桁位置を揃えて書くと見やすい」と言っているだけである

おっしゃっていることはもちろんわかるのですが、

>「こんな用途に switch は使うべきでない」とか、「配列を使ったほうがよい」

と言っている人は、「複数行にせず、桁位置を揃えて書くと見やすい」場合、そもそもロジックに問題があると言っているのではないかと思うのです。

すなわち配列を使うなり、ディスパッチテーブルを使うなり、普通にコーディングしていれば、そんな「コーディングスタイルの常識をぶち壊」さなければならないような状況は発生しない、と。

だからこそ、「そうでない」と言いたいならば、替えが効かないような例を出さなければいけないわけです。

ちなみに
>コードを印刷してチェックする
というのは噴飯物ですね。

10 ■無題

>「カレンダーなんて OS に付属しているのに、なんでそんなもの作るんですか?」という人がいる。なんという的外れな意見だろう

私は的外れではなく当然の疑問だと思いますが。

「ソフトを作る」ことと「プログラムを書く(プログラミング言語を学ぶ)」ことは異なる。初心者はいきなりゲームを作ろうとして挫折することが多い。

課題を出す前にそのことをまず教えるべきだと思いますよ。(なんてことを書くと「『日常生活で齟齬がよく起こる』という例を出したいのであって、プログラミング言語教育の話をしたいのではない。そもそも私は教師ではない」と言われるかもしれませんが…)

9 ■無題

今日のランキング同着だったのでお邪魔しましたw
お互いがんばりましょー♪

8 ■RE: 常識

秋さん、コメントありがとうございます。

この手の、記事内容とコメントの齟齬というのは、「主旨が読者に伝わっていない」ということが原因だると思います。

主旨が理解された上で考え方が違う、というのはいいのですが、主旨が伝わっていない場合は、書き手にとっても、それを読む第三者にとっても、もどかしいものです。

原因は読み手にあるだけとも限らず、記事の書き方がに問題があるのかもしれないですし、気軽に書き込みができるネットだからこそ、書き手としても、読み手としても気をつけたいと思います。

もちろん、ビジネスでのドキュメントやメールにおいては、いうまでもないことです。

7 ■無題

大変失礼しました
先ほどのコメントですが、名前の誤記がありましたので
訂正してお詫びします
正しくは「argvさんの記事」でした
コピペ指向の罠でした、失礼しました

6 ■常識

こんにちは、最近プログラミングを始めております秋です
リンク先の記事、大変面白く、またお手本になるような記事で面白いものでした。
でも、それは自分がまだ始め立てだったからなのでしょうか・・?
記事先のコメントみると常識をぶち壊せなのに
常識だろ、的な様な物やperoonさんが記事で仰って多様な、例題にケチつけるようなものが多いように見受けられました。
人間、長年やってきた物に対するこだわりとは
ぶち壊せない物なのでしょうか…。
色々と考えさせられました
これからも面白い記事楽しみにしております
がんばってください!

5 ■RE: 無題

HUNTER さん
普通に「読めない」ソースってありますね。
書いた人は読めるんだろうか、と思います。
そのときは読めてたとしても・・・。

peroon さん
ここでは「物を作ること」が目的ではなく、「作り方を学ぶ」ことが
目的ですから、その題材が「既にこの世にあるかどうか」は、
全く関係ないわけで・・・。

4 ■無題

「なんでカレンダー?」っていう人は、「この世にないものを作らないと意味がない」って考えているのかも。プラスにとらえるとね。

3 ■無題

 この御時世、一言に常識と言っても
各自が「当たり前」、「普通」、「これまで通り」
と置き換える人がかなり多いですから
理解して貰う迄に、かなりの時間を要する時も
有ったりします

 因みに…Free formatの処理系で
Sourceを「読み返さない」のでは無く
他人の組んだSourceが「読めない」場合
どうやってDebugするんでしょうねぇ…
(Magic Numberならぬ、Magic Source化?)

2 ■RE: 無題

kensir0u さん、こんにちは。

結局は、物の見方、考え方の「切り口」を変えるるということかと思います。定量的な切り口で語られない世界で、「量」を語れば常識が覆るかもしれませんが、その逆も然り。

1 ■無題

常識をぶちこわすには定量的な裏づけを取った論法で攻めることですね。
まーでも常識が基本定量的に正しいとされている論法であることが常ですからなかなか難しいでしょうねー。

コメント投稿

AD

ブログをはじめる

たくさんの芸能人・有名人が
書いているAmebaブログを
無料で簡単にはじめることができます。

公式トップブロガーへ応募

多くの方にご紹介したいブログを
執筆する方を「公式トップブロガー」
として認定しております。

芸能人・有名人ブログを開設

Amebaブログでは、芸能人・有名人ブログを
ご希望される著名人の方/事務所様を
随時募集しております。