1 | 2 | 3 | 4 | 5 |最初 次ページ >>
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)
2008年09月27日(土)

コピー指向プログラミング

テーマ:コーディング

以前、「簡単コピー・プログラミングの罠 」という記事で、コピー・プログラミングの危険性について書いた。ここでいうコピー・プログラミングとは、同じアプリケーション開発の中で、似た機能を量産するためにソースコードをコピーすることである。同記事には書いていないが、他にも、「バグがコピーされてしまう」問題や、ソースコードが無駄に大きくなるなどの問題もある。


そもそも、プログラミングでは「同じことを何度も書く」ということは避けるべきだ。その理由をあらためてここに書く必要もないだろう。同じことを何度も書かずに済ませるにはどうするか、ということは、構造化プログラミングからオブジェクト指向やアスペクト指向に至るまで、プログラミング技術の発展における重要な課題のひとつだったはずだ。


アプリケーションに固有の「業務ロジック(ビジネスロジック)」なども、開発プロジェクト内で共通化を行い、重複コードをなくすのが理想である。これには、開発期間の不足や業務面・技術面でのスキル不足など、多くの問題があるが、最もやっかいなのは、多くのプログラマがコピー・プログラミングを好むということである。


あるプロジェクトで共通機能(基底クラス)を作ったら、そのソースを部分的にコピーして使う人がいて、更にそれをコピーして作る人が出てきて、結局コピーだらけになったという例もある。これには「プログラマの管理がうまくいっていない」という指摘もできる。しかし、それ以前に、プログラマに「コピー・プログラミングへの抵抗感がない」ということが問題なのである。


実際、多くの職業プログラマを自由にしておくと、むしろ好んでコピー・プログラミングを行うようである。みんなコピー・プログラミングが大好きなのだ。



たしかに、チーム開発で共通化をしようと思うと、他のメンバーと相談して仕様を決めたり、あるいは他のメンバーの作った複数のソースを変更したりと面倒なことは多い。そういう役割の人(「共通チーム」などと呼ばれる)ならともかく、単なる「一機能の担当者」であるプログラマが、共通化のためにそこまでの労力を払うことは、まずないだろう。


コピー・プログラミングなら、誰にも気兼ねすることなく、自分の担当機能を作ることができる。多くの職業プログラマにとっての最優先課題は「自分の担当機能を動くものに仕上げること」であって、「ソースコードが美しいかどうか」などは二の次なのである。



私はこれまでコピー・プログラムには何度も痛い目にあってきたので、自分のプロジェクトでは、いかにして共通化を徹底するか(コピーさせないか)、ということに頭を悩ませてきた。しかし、多くのプログラマがコピーが大好きなのだとすれば、それを前提とした開発方法を考えるのも一興である。たとえば、以下のようなことだ。



あらかじめ完成度の高い「コピー元」を用意する

コピー元を品質の高いコードに集中させることで、「バグのコピー」や「似て非なるバージョンの散在」を防ぐ。



「コピーされたもの」が分かるようにする

例えば、コピー元のコードに特殊なコメントを埋め込む(もちろん、コピー先でも消さないでおく)などして、後からコピー先を検索しやすくする。これは、不具合修正や仕様変更などの際に、影響範囲(全てのコピー先)を特定しやすくするためである。



コピーしたコードは可能な限り変更しない

まず、コピー元はなるべく変更しなくてすむように作る。例えば、コピー先で関数名などがぶつからないように、ネーミングルールを作る。また、コピー先で無駄に変更することも禁止する。動作に影響のないからといってコーディングスタイルを自分流に変えたりしない。コピー先の記述の変更量が少なければ、コピー先の特定がしやすくなるし、記述の統一による可読性の向上にも繋がる。


あるいは、開発ツールの助けにより、コピー・プログラミングの品質向上が見込めるかもしれない。既存のツールでも、例えば、Visual Studio 等の統合開発環境で、アプリケーションの雛形を作ってくれる「ウィザード」や、「よくあるコード」を挿入してくれる「コードスニペット」は、「コピー指向」であると言ってもいいだろう。ソースコードを現在のようなテキスト形式のみで保存することに拘らなければ、他にも色々な対策はできそうだ。例えば、どのコードがどこへコピーされたか、ということをエディタが記録してくれれば、後から追跡することが容易になるだろう。



私も「同じことを何度も書くべきではない」という考え方を変える気はない。しかし、同じプログラマといっても、プログラミングについて誰もが同じように考えているわけではない。むしろ自分のようなプログラマは少数派なのかもしれない。そう考えると、日々の「悪態」も少なくなってくるのである。







■関連記事
簡単コピー・プログラミングの罠
簡単フレームワーク・プログラミングの罠
スキルアップのためにラップを剥がしてみる




アスペクト指向入門 -Java ・ オブジェクト指向から AspectJプログラミングへ
千葉 滋
技術評論社
売り上げランキング: 158663
おすすめ度の平均: 4.0
4 入門書として良く出来てます


初めてでもカンタン コピーするだけですぐに使えるJavaScript
立山 秀利
ローカス
売り上げランキング: 115209
おすすめ度の平均: 4.0
4 「とにかく今すぐ使いたい」と言う人向きです。
AD
いいね!した人  |  コメント(15)  |  リブログ(0)
2007年04月22日(日)

ハンガリアン記法

テーマ:コーディング

変数などの名前を付ける時のコーディングルールに、ハンガリアン記法(ハンガリー記法)と呼ばれるものがある。簡単に言えば、名前の先頭に「型」などを表す文字列(プリフィックス)をつけるというものである。


かつて Microsoft が好んで採用しており、 Visual C/C++ (MFC) を使ったWindows プログラミングの仕事が多かった私の会社では、社内ルールとしても採用されている。



というわけで、私も、ハンガリアン記法で多くのコードを書いてきたのだが、あるとき、Joel Spolsky 氏の「間違ったコードは間違って見えるようにする 」という記事を読んでショックを受けた。


それまで私が書いてきたハンガリアン記法というのは、MFC でやっているように、変数名に「型(type)」を表すプリフィックスを付けるものだった。しかし、それは「システムハンガリアン」と呼ばれ、本来のハンガリアン記法ではなかったのだ。


本来のハンガリアン記法とは、「アプリケーションハンガリアン」と呼ばれ、プログラミング言語の「型」とは無関係に、データの「種類(kind)」を変数名で表現する方法であった(※1)。


アプリケーションハンガリアンを使えば、変数間の互換性(端的に言えば、代入してもよいかどうかということ)が、コードの読者(コードを利用する人、改造する人、デバッグする人、レビューする人、そして、そのコードを書いた人自身)に明確に伝わる。ここでいう互換性とは、文法的なものではなく、意味的なものである。文法的な互換性はコンパイラがチェックしてくれるが、意味的な互換性は人間がチェックするしかない。


つまり、本当に有用なのは、文法的な「型」を明示するシステムハンガリアンではなく、意味的な「種類」を明示するアプリケーションハンガリアンなのである。



今では、Wikipedia にも「アプリケーションハンガリアン」と「システムハンガリアン」の違いが記述されている(※2)。しかし、古参のプログラマは、あらためてハンガリアン記法の意味など調べない人がほとんどだろう。一方で、Microsoft からシステムハンガリアンが消えようとしている時代にあって、新参のプログラマが、ハンガリアン記法について考える機会はどんどん少なくなるだろう。


しかし、そんな時だからこそ、アプリケーションハンガリアンの価値を再考すべきではないだろうか。特に、自前のコーディング規約の作成を考えている人には、是非とも先に紹介した記事は読んでもらいたい。プリフィックス方式を採用するかどうかは別にしても、少なくとも、意味的な種類(kind)を明確にする、という考え方は取り入れるべきだろう(※3)。







※1
もちろん、アプリケーションハンガリアンを使わない場合でも、変数名はデータの意味的な「種類(kind)」を表すようにすべきだ。しかし、それをプログラマ個人に任せてしまうと、不統一になってしまって意味がない。ルール化するということが大切なのだ。


※2
2007/4/22 現在。Wikipedia の項目名は「ハンガリー記法 」となっているが、「ハンガリアン記法」への改名が提案されている。


※3
システムハンガリアンのルールを作るのが簡単だが、アプリケーションハンガリアンのルールを作るのは難しい。しかし、Joel Spolsky 氏の記事にある「本当の解決法」はそのまま使えるし、他のルールを作る上での参考にもなる。また、類似したデータを取り違えてバグになった経験を思い出せば、いくつか思いつくのではないだろうか(例えば、「YYYYMMDD」と「YYMMDD」、「ゼロ埋めしているデータ」と「ゼロ埋めしていないデータ」、「枝番つきコード」と「枝番なしコード」、「協定世界時」と「日本標準時」、文字コード違いの文字列・・・)。



■関連記事

チームのために自分のスタイルを曲げる覚悟
慣例的コーディングルール
プログラムに操られた男
その名前、紛らわしい!
読者指向プログラミング




Joel on Software
Joel on Software
posted with amazlet on 07.04.22
Joel Spolsky 青木 靖
オーム社 (2005/12)
売り上げランキング: 1815
おすすめ度の平均: 4.5
5 実際に現場で使わせてもらってます
3 優秀なソフトウェア開発者の日々の徒然
3 プログラミングチームを率いるときに


C++ Coding Standards―101のルール、ガイドライン、ベストプラクティス
Herb Sutter Andrei Alexandrescu 浜田 真理 浜田 光之
ピアソンエデュケーション (2005/10)
売り上げランキング: 37199
おすすめ度の平均: 5.0
5 上級者には心得集、中級者にはポインタとして
5 この二人以上にC++について語れますか?
5 文法だけでは分からない、C++の書き方

AD
いいね!した人  |  コメント(7)  |  リブログ(0)
2007年01月21日(日)

整理されたコードが読みにくい理由

テーマ:コーディング
@IT の「キミのコードが汚い理由 」という記事を読んだ(yasuhoの隠れ家 さん経由)。

この記事には、テニスのスコアをつけるための2つの Java コード紹介がされている。「幼稚なスタイル」で書かれたとされる「リスト1」と、それを「クリーン」に書き直したとされる「リスト2」である。記事の中では、これらは単なる「前フリ」程度の扱いなのだが、「読者指向プログラミング 」ということを考える上で、おもしろい題材なので、少し細かく見てみようと思う。

元記事の趣旨に対しては「重箱の隅」的な指摘になるかと思うが、それは承知の上で、別のテーマとして読んでいただきたい。

まず、元のソースコードは画像で公開されているので、テキストにしたものを以下に示しておこう。

リスト1

public class SetScorer
{
private int[] games = {0, 0};

public void gameWon(int i){
games[i-1]++;
}

public String getSetScore(){
if ( games[0] < 6 && games[1] < 6) {
if(games[0] > games[1]){
return "Player1 leads " + games[0] + " - " + games[1];
} else if (games[1] > games[0]) {
return "Player2 leads " + games[1] + " - " + games[0];
} else {
return "Set is tied at " + games[1];
}
}
if (games[0] == 6 && games[1] < 5) {
return "Player1 wins the set " + games[0] + " - " +
games[1];
}
if (games[1] == 6 && games[0] < 5) {
return "Player2 wins the set " + games[1] + " - " +
games[0];
}
if (games[0] == 6 && games[1] == 5) {
return "Player1 leads 6 - 5";
}
if (games[1] == 6 && games[0] == 5) {
return "Player2 leads 6 - 5";
}
if (games[0] == 6 && games[1] == 6) {
return "Set is tied at 6 games";
}
if (games[0] == 7) {
return "Player1 wins the set 7 - " + games[1];
}
return "Player2 wins the set 7 - " + games[0];
}

}

リスト2

public class SetScorer {
private int[] gamesWon = {0, 0};

public void gameWon(int player){
gamesWon[player-1]++;
}

public String getSetScore(){
int leader = gamesWon[0] > gamesWon[1] ? 1 : 2;
int leadersGames = gamesWon[leader - 1];
int opponentsGames = gamesWon[leader == 1 ? 1 : 0];
String setScoreMessage = null;
if ((gamesWon[0] < 6 && gamesWon[1] < 6)
|| (leadersGames == 6 && opponentsGames == 5)) {
setScoreMessage = "Player" + leader + " leads " +
leadersGames + " - " + opponentsGames;
} else if (gamesWon[0] == gamesWon[1]) {
setScoreMessage = "Set is tied at " +
leadersGames;
} else if (( leadersGames - opponentsGames >= 2)
|| leadersGames == 7) {
setScoreMessage = "Player" + leader +
" wins the set " + leadersGames + " - " +
opponentsGames;
}
return setScoreMessage;
}
}


yasuhoの隠れ家さんも指摘されているように、リスト1の方が分かりやすいと感じる人も多いのではないだろうか。確かに、リスト2は数式的には「整理」はされているのだが、読みやすくはないように思える。

いくつか、その原因を考えてみた。


1. レイアウトへの配慮がない


空行挿入、改行位置、インデントなど、レイアウトについての配慮が甘く、全体的に、目で追いにくい書き方になっている。もっとも、これは Web 掲載上の都合かもしれない。



2. 変数の扱い方の問題


リスト2では、リスト1より変数が多くなっている。ここでは「優勢なプレイヤー」と「劣勢なプレイヤー」の勝ち数を明確にする意図があり、それ自体は悪いことではない。

しかし、せっかく配列の内容を leaderGames、opponentGames という変数に入れ直しているのに、その後も元の配列を参照し続けているので、逆効果になっている部分がある。例えば、「gameWon[0] < 6 && gameWon[1] < 6」は単に「leaderGames < 6」でいいし、「gamesWon[0] == gamesWon[1]」も「leaderGames == opponentGames」でいい。

また、2人のプレイヤーを数値で区別しているのだが、「0 と 1 で区別する場合」と「1 と 2 で区別する場合」が混在していて分かりにくい。そもそも、プレイヤーが2人しかいないのに、配列にする必要があるだろうか? このあたりは、リスト1の書き方に引きずられている印象だ(比較しやすいように意図的にそうしているのかもしれないが)。

更に細かいことを言えば、"set" で始まる変数名があるが、これは一見、関数(setter)のように見えるので、避けたほうがいいだろう。



3. 直感的表現の消失


「幼稚なスタイル」のコードは、幼稚であるが故に読者にとって「直感的」であることも多い。逆に、コードを「整理」すると、その代償として、素直な表現が失われてしまうことがあるのだ。

例えば、リスト1の if 文は処理としては冗長なのだが、条件が馬鹿正直に書かれているので、逆に分かりやすい。

また、return しているメッセージの文字列も、リスト1ではやはり馬鹿正直に書かれているため、「文」として意味を取りやすい。コード内の文字列は、往々にして、そこで何が行われているのかを伝えてくれる。いわば「コメント的な効果」を持っているのだ。リスト2のメッセージは変数で分断されている箇所が多く、この効果が薄れている。

もちろん、私もリスト1のような「幼稚な」書き方が良いなどと言うつもりはない。効率や汎用性、あるいは「他の角度から見た読みやすさ」のために、こうした直感的な表現が犠牲になることは、宿命だろう。しかし、そうした表現の効果について、知っておくということは必要である。「読者指向プログラミング」のテクニックのひとつになりうるからだ(※)



4. 読者層が想定外


これは読者側の問題になるのだが、英語が苦手な読者にとって、変数名が直感的に理解できないという問題もある。個人的には、"leader" や "opponent" といった単語が「優勢なプレイヤー」とその「対戦相手」であると理解するために、変数に代入している式を解読する必要があった。つまり、変数名が「a」や「b」でも同じだったわけだ。

多くのプログラミング言語で、ソースコードはアルファベットと数字と記号で書くことになっている。このため、日本人向けのコードには、より多くのコメントが必要になる(漢字という「表意文字」の効果は絶大である)。しかし、リスト2の作者は日本の読者を想定していなかっただろう。



こうした点を考慮しながら、リスト2を修正してみよう。といっても、全ての問題を同時に解決することはできない。全体のバランスを考えた「落とし所」を見極めることが必要だ。

リスト3

public class SetScorer
{
private int[] gamesWon = {0, 0};

public void gameWon(int player){
gamesWon[player-1]++;
}

public String getSetScore(){

// どっちが優勢か
int leader = gamesWon[0] > gamesWon[1] ? 0 : 1;
int leadersGames = gamesWon[leader];
int opponentsGames = gamesWon[leader == 0 ? 1 : 0];

String scoreMessage = null;
if ((leadersGames < 6) || (leadersGames == 6 && opponentsGames == 5)) {
// 試合途中
scoreMessage = "Player" + (leader + 1) + " leads "
+ leadersGames + " - " + opponentsGames;
} else if (leadersGames == opponentsGames) {
// 同点
scoreMessage = "Set is tied at " + leadersGames;
} else if ((leadersGames - opponentsGames >= 2) || leadersGames == 7) {
// 試合終了
scoreMessage = "Player" + (leader + 1) + " wins the set "
+ leadersGames + " - " + opponentsGames;
}

return scoreMessage;
}
}

読みやすさという点において、いくらか良くなっていると思うが、どうだろうか。もちろん、コードの書き方に「正解」はない。私が自分でゼロから書いたとしたら、また違ったコードになるだろう。「読者指向プログラミング」について考えるには、適度な題材である。プログラマの方は、自分ならどう書くか、実際にやってみてはいかがだろうか。






※例えば、これは何をする関数だろうか?

 double func(double r){ return r * 6.28; }

では、これは?

 double func(double r){ return r * 2.0 * 3.14; }

「3.14」と書けば「円周率」だと分かるため理解しやすい。つまり、これらは半径を r とする円周の長さを求める関数である。前者の方が数式としては「整理」されており、効率もよいかもしれない。しかし、後者の方が読者指向である。



■関連記事
読者指向プログラミング
もっとコメント論 ~その1~ コメントとは何か
インデントについて考える 前編
誰のためのコード?
まずは丁寧なプログラミングを
プログラムは二度書け
慣例的コーディングルール



Code Complete第2版〈上〉―完全なプログラミングを目指して
スティーブ マコネル Steve McConnell クイープ
日経BPソフトプレス
売り上げランキング: 2788
おすすめ度の平均: 5.0
5 これは理解できないとヤバイです。
5 我流プログラミングから抜け出す意思のあるひとへ
5 人に勧めたくなる本


続 直観でわかる数学
続 直観でわかる数学
posted with amazlet on 07.01.21
畑村 洋太郎
岩波書店
売り上げランキング: 86453
おすすめ度の平均: 4.0
2 自分で考える覚悟があるか
4 解説と算数授業の批判
5 目からウロコの算数

いいね!した人  |  コメント(17)  |  リブログ(0)
2006年12月24日(日)

読者指向プログラミング

テーマ:コーディング
私は英語は苦手である。辞書があれば、英文を読むくらいなら何とかなるが、書く方はほとんどできない。日本語の場合も、読むよりも書くほうが難しいと思う。実際、こうしてブログを書いているが、なかなか上手く書けず、何度も書き直している。

しかし、プログラムのソースコードは、読むよりも書くほうが簡単な気がする。なぜだろう。


ソースコードを読むのが難しい理由のひとつは、プログラマによって書き方が大きく違うという点だろう。日本語の文章に例えれば、色々な方言が混ぜ合わされて書かれているようなものだろうか。

なるべく書き方が揃うようにと、「コーディング規約」のようなものを設けることも多いが、細かいところまでルール化するのは難しく、どうしてもプログラマの癖のようなものが出てしまう。

TMTOWTDI という言葉があるように、色々な書き方があるということは、必ずしも悪いことではない。しかし、コードの読みやすさという点に限って言えば、それを難しくしている要因のひとつだろう。


コードを読むのが難しいもうひとつの理由は、「表現下手なコード」が多いということだ。日本語でも、ブログなどを読んでいると、何を言いたいのか全く分からないような文章に出会うことがあると思う。ソースコードでは、それがもっと頻発する。

文章を書く場合は、その第一の目的が「伝える」ということなので、書き手は読みやすさということを意識するものだ。しかし、ソースコードを書く場合は、「伝える」ということ以前に「プログラムが正しく動作すること」に意識が行く。そのため、可読性はなおざりにされがちなのだろう(「誰のためのコード? 」も参照)。


同じ機能のプログラムを作る場合でも、ソースコードは色々な書き方ができる。そんな中で、より読みやすい「表現」を選ぶこと。私はそれを「読者指向プログラミング」と呼んでいる。読みにくいコードはバグを混入させやすく、変更もしにくい。同じ機能を作るなら、読みやすいコードを書くべきである。

読みやすい文章を書くためには、ある程度の技術が必要である。それと同じ様に、読みやすいコードを書くためにも技術が必要だろう。例えば、関数設計、クラス設計が上手くできなければ、読みやすいコードを書くことはできない。しかし、読者志向プログラミングでもっと大事なことは、「読者を意識する」ということである。そして、どう書けば読みやすくなるか、ということを考えることだ。


プログラミング初心者には、どんなコードが読みやすいか分からないかもしれない。最初は、とにかく他人のコードを読むという経験が必要だろう。自分で多くのコードを読めば、どんなコードが読みやすく、どんなコードが読みにくいか、よく分かるようになるだろう。

そもそも、プログラマにとって、コードを読むことは、コードを書くことと同じくらい重要である。他人の書いたコードをデバッグしたり、改造したり、流用したりする際には必須のスキルだ。入手可能なコードは積極的に読み、読みにくいコードも読みこなせるような力をつけることも必要だろう。





■関連記事
誰のためのコード?
まずは丁寧なプログラミングを
プログラムは二度書け
慣例的コーディングルール
TMTOWTDI ~ 人生色々、プログラミングも色々



ソースコードリーディングから学ぶ Javaの設計と実装
WINGSプロジェクト 佐藤 匡剛 山田 祥寛
技術評論社
売り上げランキング: 9274


Code Reading―オープンソースから学ぶソフトウェア開発技法
トップスタジオ まつもと ゆきひろ 平林 俊一 鵜飼 文敏
毎日コミュニケーションズ
売り上げランキング: 50755
おすすめ度の平均: 4.0
3 意外なほどに教科書的な内容
4 ホップ・ステップ・ジャンプ
3 例題がわかりにくい


いいね!した人  |  コメント(4)  |  リブログ(0)
1 | 2 | 3 | 4 | 5 |最初 次ページ >>

AD

ブログをはじめる

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

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

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

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

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