でぃするだいありー？

そんな気はないんだれど、でぃすっちゃってる。 でぃすでれ？

CODE COMPLETE

書籍・雑誌 パソコン・インターネット

動機

ここ数年、Python、Kotlin、node.js、Flutter、GOなど、仕事では使ったことのないプログラム言語に意図して接してきた。
そのせいか、自身のコーディングがどの程度スタンダードから乖離しているのか気になってきた。それぞれ独特の作法があり、似て異なる構文があったりすると、慣れた言語のやり方に引っ張られて、対象となっている言語の特徴を引きだせていないのではないかという懸念である。

総評

「コードをきれいに書きましょう。そのために有用と思われる著者の経験を語ります」という内容。本書と違っていつ読んでもいい『闘うプログラマー』と並ぶ必読の書。
余談だが、著者はポインタとgoto文、ポンティアックアズテックに妄念ともいえる感情を抱いている。コードの品質に関わる全てはこれらのワードが密接に絡んでいるということらしい。
個人的には特に思うところはないが、世間的にアレなVisual Basicをポジティブに扱っているのが意外だった。

本書の対象と思われる読者

難しい内容ではないので、ほどほどに経験を積んだプログラマにはすぐにでも読んでもらいたいと思える。ただし、ほどほどに経験を積んでいないとピンとこない内容でもあると思う。
１～３年日常的にプログラミングを行っているか、あるいは本書が扱っている言語（C、C++、Java、Visual Basic）またはオブジェクト指向言語に忌避感を覚えないならば、言語そのものや本書に頻出するプログラミングあるあるに戸惑わずに、なんらかの発見があろうと思う。野生のプログラマなら聞いたこともないような内容に出くわすかもしれない。
自身のようにン十年の経歴があり、かつ上記で示したような動機があれば、セルフチェックあるいはトランキライザー、または異端審問として機能すると思う。

【分冊版】

【合本版】

上巻

所感

命名

自身によるオブジェクト指向プログラムの品質にばらつきがあるという自覚はあった。原因としては、体調、月齢、言語に依存するのだろうくらいにしか考えてこなかったが、命名が苦手だからであろうという確信めいた啓示を本書から受けた。
命名が苦手であることは長らく自覚していて、というのもTRPGやCRPGで自キャラの命名にすら悩むからである。個人的には変数や関数名に日本語が使えるならば、使ってはまずい明確な理由がなければ、命名に悩まなくて済むというだけの理由で使用を躊躇わない。ローマ字より遥かに良いとも思う。というか、一意にならない時点でローマ字はアウト。会社員時代に痛感し、以来、そのようなプログラムをメンテする場合は常に憂鬱になる。仕様書やコメントを書かない人類はローマ字使うの禁止。
さておき、なんちゃって英語ではイカンっぽいという天啓を得た。アースシーの魔法使いにはなれぬ。

PPP

疑似プログラミングプロセス（Pseudocode Programming Process）。個人的には、VB4だか6だかをやっていたときにやり始めていたように思う。1997年くらいか。その手法を身につけた経緯は覚えていないが、当時所属していた組織の同僚から教えられたか、UMLの書籍あたりから拾ったのだろう。PPPという名前がついていることは今回初めて知った。
PPPを主体として語られる9章において示される例題は自身のコーディングスタイルとかなりマッチし、本書の古さが懸念ではあるが、自身のやり方の少なくとも一部はスタンダードとして知られる書籍と大きく乖離していないことを確認できた。

11章 変数名の力

プログラマーは信仰と無縁ではいられない。個人的にはニュートラルでいたいと思っているが、唯一、COBOLだけは邪教認定している。
古典に属する内容であるからかもしれない。著者の信仰ゆえに、一部フェアでないと受け止められる表記があったからかもしれない。
この章によって、他にも無自覚の信仰が自身に宿ってしまっていたことを確認させられた。

goto文

正確には「必要だったら使え」という主張なのかもしれないが、文章から受けるいささかアンフェアな印象からすると、著者はgotoにはどちらかというと好意を抱いているように見える。そして、goto不要論者に恨みを抱いているように見える。
2016年にCOBOL、2017年にBasicの仕事に従事したという個人的事情がなければ、gotoなどいまさら議論する必要もあるまいと思っただろう。だから、個人的にはそれしか方法がないなら使え、既存プログラムを尊重するなら使え、である。

引用

P.172

　これらの例の問題点は、クライアントコードをクラスのパブリックインターフェイスではなく、そのプライベートな実装に依存させていることだ。クラスの使用法を理解するためにクラスの実装を調べていることに気付いたら、それはインターフェイスに対するプログラミングではない。インターフェイスを通じて実装に対するプログラミングをしているのである。インターフェイスを通じてプログラミングすれば、カプセル化は崩壊する。カプセル化が崩壊し始めれば、抽象化も時期に崩壊する。

　ほぼ初心者がKotlinでFragmentを使用したとき、上記のような例に遭遇した。本書は「古典」と評される向きもあるようで、特にVisual Basic万歳な印象も受けることから万能の処方箋ではないと認識しているが、その一方でほぼ初心者がKotlinでFragmentを使用したとき、Contextになにを与えればいいのか即座にはわからなかったという事例に遭遇してみれば、古典でVBマンセーであっても真理に近いことを語っているのではないかと思ったりする。サンプルプログラムで使用法を説明するような実装であるから、サンプルからちょっと逸脱したことをやろうとしたときワケワカメになるのではないかと。

P.560

　「プログラミングの複雑さ」を表す一つの基準は、プログラムを理解するために頭の中で一度に整理しなければならないオブジェクトの数である。この頭の中でのお手玉は、プログラミングの最も難しい側面の一つであり、プログラミングが他のアクティビティよりも集中力を必要とする理由でもある。プログラマが「不意の割り込み」に怒るのはそうしたわけがある。お手玉を披露している大道芸人に、ちょっと買い物袋を持っていてと頼むようなものなのだ。

下巻

所感

第23章 デバッグ

下巻「第20章 ソフトウェアの品質」「第21章 コラボレーティブコンストラクション」「第22章 デベロッパーテスト」でちょっとずつ不安を抱かされ始めたが、本章で一安心。自身のデバッグのスタンスは悪くないようだ。取り入れるべき手法や、今後の指針についても指標を得られたように思う。

第25章 コードチューニング戦略

自身はアセンブラによるチューニングの経験・スキルは保有していない。それを除いて概ね自信の経験・考え方と一致する。とらんきらいざぁ。

第7部 ソフトウェア職人気質とは

このパートに含まれている「第31章 レイアウトとスタイル」は、下巻で最長の章。著者自信が認めているように信仰の問題を含んでいるので、著述もそれから免れていない。
読んでいるさなか、これまで経験したこと、すなわち供養されていない敗戦の記憶が次から次へと脳裏によみがえってきて、読書に集中できなかった。
第7部だけは、あらゆるソフトウェア技術者に早めに読んでおいてほしい内容と思える。初心者にはピンとこないかもしれないが、それでも。

参考文献

本書には40pにも渡る参考文献のリストが添付されている。そこから、自身用のメモとして抜粋。