Hatena::ブログ(Diary)

杉風呂2.0 - A Lifelog -

2013-01-20(日)

[]『リーダブルコード』を他書と読み比べる(その1)

よい本なので、他書と比較しながら再読していきます。短期集中連載のつもり。

1章 理解しやすいコード

ここでは本書の根底となる「すべての原則が生じるテーマ」と「読みやすさの基本定理」について説明がされています。

コードは理解しやすくなければいけない。

コードは他の人が最短時間で理解できるように書かなければいけない。

C++ スタイルブック (IT Architects’ Archive―CLASSIC MODERN COMPUTING)』の「はじめに」には次のように書かれています。

チームが成果を上げるには、誰もが、他の人の書いたコードを読んで理解できなければならない。

Code Craft ~エクセレントなコードを書くための実践的技法~』1章「防御的プログラミングの技法」には次のように書かれています。

簡潔性よりも明瞭性を重視してコードを書く

簡潔ではあるのものの混乱を招くおそれのあるコードと、明瞭ではあるものの長く退屈に感じられる可能性のあるコードのどちらかを選べる状況では、洗練性には多少欠けるとしても、誤解なく明確に意図を読み取れるコードの方を使用します。(中略)自分が書いたコードが誰かに読まれる可能性があるのかを考えてみてください。そのコードの保守を比較的経験の浅いプログラマーに任せなければならない場合もあるかもしれません。その担当者がコードのロジックを理解できないとしたら、間違いが起きることは必至でしょう。複雑な構文や言語仕様を巧みに利用した小技を使えば、演算子の優先順位を知り尽くした博識ぶりを見せつけることはできるかもしれませんが、それによってコードの保守性は無残に損なわれてしまいます。「コードは常にシンプルに」が鉄則です。

Javaプログラミングの処方箋 (Programmer’s foundations)』には、逆に読みにくいコードがもたらす弊害について書かれています。

このようなコードは非常に読みにくく、このあとにこのコードを読む人に誤解を与えます。また、一度このような「汚いコード」が入ると、その汚いコードがほかにもどんどん波及していきます。元のコードが美しければ、それを「汚す」には勇気がいりますが、もともとが汚ければ誰しもコードを綺麗に保とうとしなくなります。

プログラマのためのサバイバルマニュアル』には次のように表現されています。

人は、複雑さの逆と言われると、単純を思い浮かべる。しかし、私たちの分野には避けられない複雑さがあるので、いつでも単純なコードが書けるとは限らない。複雑さの反対語としてより適切なのは、明快である。あなたのコードがしていることは、読者にとって明解だろうか。

プログラマのためのサバイバルマニュアル』は上記文章のあとで「2つの明快」について説明が続くのですが、「避けられない複雑さ」というのが気になります。『Developer's Code 本物のプログラマがしていること』(電子書籍もあるよ!)第4章「複雑さ」に面白いことが書かれています。

ほとんどのアイデアーーー見た目にはシンプルなアイデアーーーはその詳細に立ち入るとひどく複雑なものになる。高いレベルで考えている限り、アイデアはいつもシンプルだ。(中略)詳細に分け入ってみれば、ロジックのどこに穴があるのか、そのすべての場所が見えてくる。詳細とはそういうものなんだ。最後まで考え抜かれていないアイデア(つまりほとんどのアイデア)はこの時点で、複雑であることから逃れられなくなる。(中略)僕らは不十分であることを恐れている。そこにその答えがある。何かをシンプルに構築すると、それが十分なもののような気がしないんだ。

『Developer's Code』ではこのあと、複雑さを「コードが書くのが難しい」ことと複雑さがユーザに転移してしまった「使うのがむずかしい」ことの2つを引き起こし、「複雑さを表に出さない」こと、コードの複雑さを嫌うあまり「リファクタリングをあまりに早い段階で行うことの危険性」についての議論になっていきます。

コーディングの際にバイブル的な本として有名な『CODE COMPLETE 第2版 上 完全なプログラミングを目指して』を参照してみると、5.2.1「ソフトウェアの鉄則: 複雑さへの対応」に、Fred Brooksの定義を引用していますね。

Brooksによれば、ソフトウェア開発を難しくするのは、本質的な(essential)問題と偶発的な(accidental)問題という、2種類の問題であるという。

どうやら、複雑さへの対応として読みやすさが重要であるようですね。また、『CODE COMPLETE』5.2.2「設計に望ましい特性」に設計の内部特性を10個挙げています。

  • 最小限の複雑さ
  • 保守性
  • 粗結合
  • 拡張性
  • 再利用性
  • 高いファンイン
  • 低いファンアウト
  • 移植性
  • 無駄のなさ
  • 階層化

このうち、保守性がリーダビリティに関係あります。

保守の容易さとは、保守プログラマのために設計することである。保守プログラマがあなたの書いているコードについてどのような質問をするか常に想像しよう。保守プログラマを顧客と見なし、見ればすぐわかるようなシステムを設計しよう。

Kent Beckは『実装パターン』で次のように述べています。

何をシンプルとするかは人それぞれだ。ツールと技術を知り尽くしたプログラマから見たシンプルは、初心者には複雑すぎるかもしれない。相手を意識したときに、よい文章が生まれるように、よいプログラムも読み手を意識したときに生まれる。読み手の少し上を行くのはよいが、あまり複雑すぎると、相手にされなくなってしまう。(中略)コミュニケーションとシンプルは一体となって働くことが多い。余分な複雑性が減少すると、システムの理解が容易になる。コミュニケーションを重視すれば、どの複雑性を捨てるべきかが明確になる。

コミュニケーションまで含めているのがKent Beckらしいですね。相手あっての読みやすさということでしょうか。読みやすさが重要ということが十分に意識できたので、明日は2章「名前に情報を詰め込む」に入りたいと思います。

2012-06-23(土)

[]The GitHub poweredby Agile渋谷で「参加のSOCIAL CODING」という題で発表しました。

このエントリは2週間後の7/7に書いています。

銀座だけどAgile渋谷

WEB+DB PRESS』vol.69の特集「詳解GitHub」に合わせて、著者で Agile渋谷の発起人でもある @HIROCASTER の頑張りで開催されたイベントでした。

The GitHub poweredby Agile渋谷

日本のSOCIAL CODINGの今を見る

http://atnd.org/events/30016

例によって、職人のレポートを引用。

The GitHub poweredby Agile渋谷 に参加してきた #Agile渋谷

http://d.hatena.ne.jp/absj31/20120623/1340463425

申し込みに出遅れたけど 、「パインアメ提供するから入れて」と冗談半分で言ったら「いいよ」という話だったのですが、それはさすがにどうよ?ということで、ちょうどタイムリーなネタを提供させて頂きました。

私のスライドはこちら。

https://speakerdeck.com/u/suginoy/p/social-coding

人前で話すのが本当に苦手で、前日とかスライドまとまらなくてヤダなーとか思ってました。なので、自分のプレゼンの出来については不問としますw。Keynoteに多少慣れたのでLTなどに挑戦しやすくなったかな。

気になる Pull Request の内容

スライドではあえて述べなかったのですが、僕のPull Request はほんと小さなバグフィックスで自慢できるようなものではなかったのですが、みなさんを高揚させたくて、あえて大げさな話にしました。このバグフィックスについては別エントリでそのうち書きたいと思います。僕個人は次の Pull Request をキメられるように精進します。

『情熱プログラマー

しゃれで引用した、『情熱プログラマー』ですが、この本には、藤村さんのプレゼンにもあったように、GitHub共同創設者のTom Preston-Werner氏による「GutHubに専念するためにMicrosoftからの30万ドルを断った」という刺激的なインタビューが掲載されているので、合わせて読まれると面白いと思います。

情熱プログラマー ソフトウェア開発者の幸せな生き方

情熱プログラマー ソフトウェア開発者の幸せな生き方

「参加」について

スライドのタイトルにも入れた「参加」というキーワードについて、『パターン、WikiXP』を引用しました。最初は『エクストリームプログラミング 第2版』(とくに第23章「時を超えたプログラミングの道」)から引用しようと考えていたのですが、この本には「参加」というキーワード直接使った記述がなく、意外でした。『パターン、WikiXP』は、何かのスキルが上がるわけではないですが、アジャイル開発をしようと思う人には是非読んでもらいたい本です。

パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)

パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)

例の動画

イベント開催後、一部の暴徒化したファンがアングラにプロモーション動画を流通させ、Twitterでステルスマーケティングを展開していますが、僕はその動画出てくるようなことは言ってませんので、ご注意ください。

ついでの話を。

今回は、某渋谷のMatzもどきの人が休憩時間に突然LTをはじめたり、某ジョジョエヴァンジェリストが乱入LTで参戦したりというイベントだったのですが、LTで発表させてくれという人なら人気の勉強会も飛び入り参加できるといいんじゃないかなぁと思いました。プロスポーツにはワイルドカード(主催者推薦枠)というのがあったりして、勉強会もそういうのが広まればいいなぁと思ったりしました。

RubyRailsコミュニティのみなさん、話を聞いてくだった参加者のみなさん、機会をくれた大塚さん、ありがとうございました。

Keep, よかったこと

  • ミニセッションを持った
  • 大場さんにフォローされた
  • GitHubを前より見るようになった
  • パインアメを提供した

Problem

  • プレゼンは気が重い
  • 実はGit力が足りない
  • 「はじめてのPull Request」企画にCollaboratorとして追加されてしまっていた
  • 行く先々でネタにされる

Try

  • 「はじめてのPull Request」企画の Collaborator 活動する
  • GItの勉強する
  • Gistを積極的に使う
  • 懇親会で借りたお金返す
  • 大場さん主催のxxx

2011-10-21(金)

[][]K&R周りに関する個人の読書録

先日、デニス・リッチー氏が亡くなられたということで、K&R周りに関する個人のつまらない読書録を紹介することで追悼したいと思います。

訃報: C 言語の開発者、デニス・リッチー氏が死去

http://developers.slashdot.jp/story/11/10/13/0224245/

(UNIX, C言語の始祖)Dennis Ritchieから学ぶべきこと

http://jp.techcrunch.com/archives/20111015what-can-we-learn-from-dennis-ritchie/

数年前、とある大規模()エンタープライズシステムでC/C++のシステム開発をしていたときのこと。

僕「俺まだK&R読んでないんだよねー。」

同僚「それ知ってますよ。リッチーアンドカーニハンってやつですよね?」

僕「それじゃK&Rにならねぇじゃん!」

という香ばしい会話をしていたわけですが、そのときにK&Rはバイブルではあるがいろいろ落とし穴があるということで、他書籍に寄り道しつつ読み進めていました。

1冊目。『C言語ポインタ完全制覇 (標準プログラマーズライブラリ)

C言語ポインタ完全制覇 (標準プログラマーズライブラリ)

C言語ポインタ完全制覇 (標準プログラマーズライブラリ)

配列とポインタの関係において、世間の多くのCの入門書は、いい加減で曖昧な説明だけを書いてお茶を濁しています(K&Rを含む。というより、この本が諸悪の根源だと思う)。そのうえ、一度配列で書いたプログラムを、わざわざポインタ演算で書き直したりして、「こういうのがC言語らしいプログラムだ」なんていってる本が非常に多いのが現状です。

諸悪の根源とまで書いてありますが、C言語の成り立ちから始まりつつも1冊まるごとポインタの本です。理解しにくい宣言周りについて、詳しく書かれています。本書の最初の方に出てくる、ANSI CのRationale(理論的根拠)の一節、「Keep the spirit of C」の紹介が素敵なので紹介します。

ANSI CのRationaleはここにあるらしいです。

ftp://ftp.uu.net/doc/standards/ansi/X3.159-1989/

1.プログラマーを信じなさい(Trust the programmer.)

2.プログラマーが、理由があって何かをしようとしているとき、それを妨げてはいけない(Don't prevent the programmer form doing what needs to be done.)

3.言語を小さく、シンプルに保とう(Keep the language small and simple.)

4.ある1つの操作のためにには、たった1つの方法だけを提供しよう(Provide only one way to do an operation.)

5.たとえ移植性が保証されていなくても、高速にしよう(Make it fast, even if it is not guaranteed to be portable.)

これがC言語なんです。書きにくいとかメモリリークだとか移植性がどうとか言っちゃいかんのです。

2冊目。『アホでマヌケなプログラミング (プログラマーズ叢書)

アホでマヌケなプログラミング (プログラマーズ叢書)

アホでマヌケなプログラミング (プログラマーズ叢書)

Lepton先生のエッセイをまとめたものです。悲惨なプログラムやシグマなど、全般的にSEの悲哀を書きつつも著者のプログラミングに対する愛情溢れた本です。10ページほどK&Rのポインタ周りをネタにした箇所があります。

3冊目。『Lepton先生のCの強化書 (開発の現場セレクション)

Lepton先生のCの強化書 (開発の現場セレクション)

Lepton先生のCの強化書 (開発の現場セレクション)

これもLepton先生の著書ですが、『開発の現場』の連載をまとめたもので、2007年初版でC99などの話題もあります。ISOの規格書やK&Rを随時参照して話が進みます。

4冊目。『叫ぶ!Cプログラマ―プロが説くCのカラクリと落とし穴

叫ぶ!Cプログラマ―プロが説くCのカラクリと落とし穴

叫ぶ!Cプログラマ―プロが説くCのカラクリと落とし穴

本書もエッセイ調に面白おかしく書かれています。有名な"hello, world."について、

つまり、「K&R」にそういう説明がないのは、やさしそうな「こんにちは世界」とは裏腹に、あの本がもともと、コンパイラというプログラムが何をするモノかとか、コンパイルされた結果のコードはどうメモリに読み込まれてどう実行されるかとか、そういうコトに関して今さら解説を必要としないヒトが読むことを想定して書かれたものだからなんである。ところが、現在の本屋でC言語の解説書を手にするヒトの90%は、前章まででオレが解説したコンピュータのごくごく簡単な様式すら理解していないのが現実である。それぢゃあCを使ってイッパシのプログラムを書くのは難しいんだよ。

と身が引き締まる文章が書かれていたりします。記憶クラス指定子の解説などが詳しいです。

5冊目。『C言語撃退講座 ~K&Rは置いて、俺の話を聞け

C言語撃退講座 ~K&Rは置いて、俺の話を聞け

C言語撃退講座 ~K&Rは置いて、俺の話を聞け

タイトルと表紙から受ける印象通り、文章がかなり香ばしく冗長な印象を受けるのですが、それも含めて楽しんでください。

6冊目。『カーニハン&リッチー『プログラミング言語C』を読む (KS)

カーニハン&リッチー『プログラミング言語C』を読む (KS)

カーニハン&リッチー『プログラミング言語C』を読む (KS)

文字通りK&Rの副読本です。

7冊目。『エキスパートCプログラミング―知られざるCの深層 (Ascii books)

実は、冒頭のプロジェクトを離れてからC言語に触れておらず、本書を読むところまで至らなかったのですが、ぜひ読みたい本です。

おまけ。 c - *sとs[]の違い / 404 Blog Not Found

http://blog.livedoor.jp/dankogai/archives/51028910.html


他にもC言語に関する書籍は読んでいますが、K&Rに言及があって比較的重くない書籍を紹介してみました(1冊を除く)。まぁ、むしろK&Rだけ読んで自分でひたすらコード書いてみた方が近道かもしれませんね。というわけで、「そこまでしないとC言語を書いてはいけないのか」という声が聞こえてきそうですが、そういう言語ではないかと思います。他にCとC++が混在した環境だと両者の言語仕様差異やコンパイラの実装依存などもあったり、そもそもUNIXのシステムコールやMicrosoft MFCの話などもないので派手なアプリケーションは作れません。今は新人研修でC言語を使わずにJavaなどの言語が使われていたり、アプリケーションを構築するには不要になりつつあります。一方で、今も様々なミドルウェアがC言語で書かれていたり、世界最大のオープンソース、LinuxカーネルもC言語です。プログラミングを極めたい人のための言語ではないでしょうか。

デニス・リッチー氏のご冥福をお祈りします。

プログラミング言語C 第2版 ANSI規格準拠

プログラミング言語C 第2版 ANSI規格準拠