【感想・ネタバレ】Code Complete 第2版 上 完全なプログラミングを目指してのレビュー

スティーブ・マコネル / クイープ

[ブクログ · ★★★★★]

マコネル本。
読んだ後に自分のプログラムを見返すと色々と粗が気付いた本。
とはいえ、最近は言語やツールチェーンで救ってくれる所が増えたので、ざっと押さえておくと良いレベルなのかも。(C言語とかは別)

[ブクログ · ★★★★★]

# 1周目 読み終えた 2022-12-22

第一部はプログラミングの前段階のよう感じで、これは期待していたようなコードの本なのかと、とっつきにくいところがあった。しぶしぶ読んでいくと、なるほど、確かにプログラミングの本であって、必要なスキルだと分かった。むしろ自分にとっては、この第一部こそ重要で、定期的に読み直す必要がありそうだと感じた。この本では要求やアーキテクチャに続く、ソフトウェアの設計やプログラミングをソフトウェアコンストラクションと呼んでいて、第一部を除くとほぼ全てがコンストラクションに当てられている。

第一部以降は、徹底的にコードを解剖して、詳細な議論が展開される。それらの多くは全く新しい考え方や技法というわけではなく、プログラミングを繰り返すことで徐々に身についてくることでもあり、基礎的かつ実際的なものとなっている。そういうの整理して、まとめ上げたというところに価値がある。驚きの新発見はないだろうけど、自身の経験から得られた考え方を、まだ漠然としたものであれば、それを裏打ちして強固なものにしてくれる、という本だった。

まだ上巻なので、あと半分残っている。

## 19章を読んだ

「制御構造の問題」

この章の主題は、複雑さにどう立ち向かうか、ということになる。とにかく単純に、単純にできればいいのだけど、限度もある。複雑さは制御構造によってもたらされるところが大きい。深いネストや込み入った条件がが代表格となる。それならば、複雑さを軽減させるために制御構造に注目するのは自然なことだ。制御構造を完全に除去することは不可能で、それは白紙のプログラムと変わらない。できる範囲で頑張ることになる。歴史的には、構造化プログラミングの方法が提案されて、解決の糸口が見えたかに思われたが、今ではほとんど廃れてしまったようだ。しかし、その考え方には有用なものもあるし、一度は学んでおく価値がある。

## 18章を読んだ

「テーブル駆動方式」

これまでとはちょっと色合いが違う章。9章の疑似コードによるプログラミングと色合いが近い。基礎的なところよりも一歩先を行った手法、考え方を提案している。考え方としてはそれほど突飛したものではない。似たような方法でプログラミングした経験はあるだろう。このように名前がつけられることでその方法がパターン化され、プログラミングのときに、そういうやり方でやっているのだと自覚できる、ということに価値がある。また、単純なテーブルへの置き換えでは対応できないケースも、キーをどうにか変換することによって対応できる可能性を見せてくれている。

## 17章を読んだ

「特殊な制御構造」

return、再帰、gotoとある。

returnは特殊とまではいかないように思える。そもそも、returnしなければ関数から値を返すことはできない。ここで言っている特殊なreturnとは、ルーチンの途中で処理を終了してしまうためのreturnを指している。この手法によって読みやすくなることは多々あり、よく使っている。一つのルーチンには一つのreturnのみしか使わないという主張を聞いたこともあるが、あまり賛同できない。

再帰のところで、階乗やフィボナッチ数に再帰を使うのは問題外、そんなプログラマがいたら別の誰かを雇うと書いてあって、ギクリとした。再帰については慎重になるべき、単純なループで可能ならそうするべきだと書かれている。

gotoは最後の手段とある。本番のコードでgotoを使ったことはない。いつか本当に必要なときが来るのだろうか。

## 16章を読んだ

「ループの制御」

前章と前々章が短かったので、この章は少し長く感じた。ループの出口によって3つケースがある。先頭と末尾はwhileとdo-whileなど対応するもがあるので、認識していた。新たな視点は、ループの途中に出口があるというパターンは盲点だった。途中が出口だと指示する特別な構文を用意している言語はないかと思われる。ただ、if cond then break といったようなループを抜け出るステートメントがループの途中にあるようなものを、先頭と末尾にあるパターンと同列に扱う。こういうパターンには何度も遭遇してきた。はっきりとこれが出口だ、と認識するかしないかの違いは大きい。なんとなくループの途中でbreakすると不安な気持ちになっていたのだけど、これは出口が途中にあるループなのだから、そのよう書いても問題ないのだと自信をもつことができる。

ループ変数の名前はi、j、kだけではだめだともっともな主張をしている。マトリックスを表現する二次元配列とかで、i、jの方がむしろ分かりやすいかと思って多用してきたけど、再考したほうがいいかもしれない。

## 15章を読んだ

「条件文の使用」

ifとcaseの話。およそ感覚的にひどいと思われるコードはだいたい実際にひどい。変な感覚を養っていなければ、自身の感覚でおや?と思うところがあれば、それは見直したほうが良いコードの兆候となっている。そんな風に感じた。caseのフォールスルーは使うべきではないし、if-elseでは正常なケースを最初に持ってくるべきだというのは、自分の習慣と一致している。本来到達するはずのないelseやdefaultにassertを置いたり、エラーにしてしまおうという考え方をする状況によく遭遇して、それが良い考えなのか自信がなかったのだけど、この章ではそれはやっても良い、と後押ししてくれた。

## 14章を読んだ

「ストレートなコードの構成」

短い章だった。一連の手続きの流れを明確にするのが目標。あまり意識していなかったところでもある。

+ 依存性を明らかにする。ルーチンの名前、引数、コメントをよく考える。
+ 実行順序が問題にならない手続きもある。関連性のあるものをまとめて書く。
+ コードは上から下に読めるようにする。

## 13章を読んだ

「特殊なデータ型」

特殊なデータ型とは何かというと、構造体、ポインタ、グロバールデータを指しててそう言っている。この本の方針からするとそうなるということで、必ずしも一般的にこのように分類がされているというわけではないだろう。

ポインタのところで喚起されている注意やテクニックは、今でも古びていないのだろうか。今となっては古びたところも見られる。少なくともauto_ptrを使うというアドバイスはもう期限が切れている。SAFE_NEWやSAFE_DELETEマクロは、今のC++ではあまり良い解決策とは思えない。ポインタの問題をなんとかして、少しでも悲劇の可能性を軽減することに効果があるのかどうか、いずれにしても、完璧な方法というのは存在しない。

これまで何度も出てきたことは、実装の詳細レベルではなく、問題領域のレベルでコードにするということ。それと、言語の中でではなく、言語の中へプログラミングするということ。どういうことかと言うと、大体は、言語が提供する機能の範囲でプログラミングするのではなく、問題のある機能を避けて、欠落している機能を補うことを規約で定めるといった感じになる。

これで第3部の変数は終わり。

## 12章を読んだ

「基本的なデータ型」

驚きの新事実といった類のものはない。なんとなくでプログラミングしても、自然と身についていくこととも言える。新たな発見がないとしても、文章化されることには大きな意味がある。なんとなくそうしているという態度を改めて、良い習慣をはっきりと認識して、基礎を強固にする効果が得られる。例えば、絶対にマジックナンバーを使わない、徹底的にリテラルを排除して名前付き定数にする、そして、なぜそうするべきなのか理由を定着させておく。第3部は4章も使って変数だけを扱っている。どの章も、基本的だがあまり文章化されてこなかったことを改めて解説することに重点を置いている傾向がある。

## 11章を読んだ

「変数名の力」

良い名前をつけるというのは永遠のテーマだ。この章は変数の名前だけの話をしている。ルーチン名やユーザー定義型などは含まれない。そのはずなのだけど、無関心ではいられない。変数名にある規則、例えば大文字で単語の区切りを表すとか設けた場合、ルーチン名やユーザー定義型の名前などの規則と区別できて矛盾しないものでないといけない。この章では、規則を重視している。凝った名前をつけるのではなく、規則性のある名前を推奨している。ちょっと風変わりな規則も紹介されていたりする。そういうのを除くと、広く認識されている内容ではないかと思う。短い変数名には強く反対している。ほとんどの場合はそれに賛成できるのだが、Go言語のような、長い名前に賛成していない言語もあったり、現状、確実に支持されている基準というわけでもないかもしれない。

## 10章を読んだ

「変数の使用」

目新しいことはあまりないく、広く普及しているアドバイスと一致するものになっている。基本に忠実で、その根拠をはっきりとさせ、きれいに整理した内容になっている。例えば、変数は初期化する、使用する場所の近くで宣言する、スコープを短くする、グローバル変数を使わないといった感じ。あとは、変数に複数の意味を持たせないというのは、意図的にやることはなかったと思うが、意識したことなかった。この章を一言で言い表すと、「変な変数の使い方をするな」ということになる。変数の使い方だけを解説した章を設けた本というのはあまりないだろう。この章では、変数の名前の付け方は扱っていない。次の章でそれだけで1つの章を使うという、贅沢な構成になっている。

## 9章を読んだ

「疑似コードによるプログラミング」

Pesudecode Programming Processを略してPPPと言うらしい。クラスやルーチンを作成する効果的な方法として推奨している。初めて聞いた。テスト駆動開発のように、通常のコーディングの手順を大胆に変更する、アグレッシブな方法だ。疑似コードは、アルゴリズムを説明するときなどによく用いられる。説明目的ではない、通常のコーディングで用いることはあまりしたことがない。色々良い効果が得られるようだが、特に目についたのは、疑似コードがそのままコメントとして残るという点。コードそのものが説明的であるべきという習慣に従っていたら、過剰にコメントをつけない習慣がついてしまった。それを矯正する目的で試してみたい気が湧いた。PPPはどういう位置づけなのかというと、同列のそれ以外の方法と比較すると分かりやすく、そしてそれらのほうが有名だ。

テストファースト開発
リファクタリング
契約による設計
ハック

最後のハックというのは、何も体系化された方法を採用しないという方法で、今の自分はここに当てはまるかもしれない。

## 8章を読んだ

「防御的プログラミング」

基本はエラーの扱い方の話だけど、エラー処理に限った話ではない。信頼できない入力に対してどうするかなどの話も含まれる。防御的プログラミングという名前はそのまま、プログラミングに対して防御的になることという意味で、うまく言い表している。こういう風に名前があることで、考えないといけないこと、実践しないといけないことが認識できるようになる。アサーションを積極的に活用するように推奨している。ただし、アサーションは絶対起こるはずのないことに対して検査することで、エラーと区別しないといけない。例外もエラーを扱う手段として考えられるが、例外の使用には中立的な立場をとっていて、現実的で同意できる。C++の場合、コンストラクタとデストラクタで例外を投げてはいけないと言っている。デストラクタでは決して投げてはいけないのは常識化している。コンストラクタまでそうなのかということは聞いたことがなかった、本当なのだろうか。開発版と製品版でエラーにどう対処するかが大きく異なってくる。製品版について特に参考になることが書かれている。開発段階でアサーションでを活用するよう書かれているのに、ユニットテストを活用するようには書かれていないことが、少し不思議に思った。事前条件と事後条件について、Stroustrupの本で読んだことがあって知っていたのだけど、その出典があって、契約による設計と呼ばれる手法の一部であると知った。エラー処理について、堅牢性と正当性のどちらを優先するかというのも決めないといけないということを知った。

## 7章を読んだ

「高品質なルーチン」

コンピュータそのものを除けば、ルーチンはコンピュータ・サイエンス最大の発明だと言っている。前章がクラスだったので、クラスから一つ階段を降りた、詳細の段階としてルーチンを扱っているのかと思ったら、そうではなかった。クラスと同等に、高品質なルーチンを書くことを重要視している。内容としては、基本に忠実であって特別おかしなことはない。凝集度の概念と分類は欠落していたので、これを機に覚えておこう。processInputのような曖昧な、広い解釈ができる名前、動詞は避けるべきというところで、全く同じ名前を使ったことがあるのでぎくりとした。一番重要なところをあげるとすると、クラスと同じように、ルーチンも複雑さを緩和するために作成するということ。

## 6章を読んだ

「クラスの作成」

オブジェクト指向に基づいた設計を行うべき立場からと言うより、歴史的にプログラミングの中心となるものが進化してきて、現段階ではそれがクラスであるという立場に立っているように感じた。オブジェクト指向の熱烈な支持者ではなく、クラスによってうまく問題を解決できるから採用しているといった現場主義な立場といってもいい。もちろんクラスを用いる以上は、オブジェクト指向から完全に切り離すことはできない。なので、オブジェクト指向について学んだことがあるなら、主流となっているガイドラインや原則にだいたい沿ったものとなっている。興味深いのは、ソフトウェア開発の歴史は、マシン命令→ステートメント→ルーチン→クラス、と進化してきたという解釈だ。クラスが広く使われるようになって、20年ほど経過している。もうクラスから新しい何かにシフトしようとという動きがあっても良い頃合いで、それにひそかに期待している。

## 5章を読んだ

「コンストラクションによる設計」

設計についてちゃんと学んだことがない。独立した開発プロセスとして設計を行った経験なくても、プログラミングにおいて誰もが自然と行っていることが、全部でなくても少なくとも部分的には、思い当たるだろうことが書かれている。理想から出発した方法論ではなく、現場の経験から生まれた一種のパターンのようなものを整理したものといえる。唯一の正しい方法があるわけではなく、こうすればうまくいくというようなことが書かれているわけではない。氷山の一角と言っているけど、自分にとってはこの章だけでも十分ヒントになる。1ヶ月に1回くらい読み直しても良いくらい。

## 4章を読んだ

とても短い章。これから先、長い旅の幕開けを予感させる。言語の選択。言語の「中で」ではなく、言語の「中へ」プログラミングする。どういうことか、まだ実感できない。言語が規定する範囲でプログラミングするのではなく、実現したいことが先に立って、それを言語が提供するツールで実現する。

## 3章を読んだ

概略

+ 上流の必要性とやり方の話。
+ 要求とアーキテクチャ。
+ 反復性と高いプロジェクトと、逐次性の高いプロジェクト。
+ 要求やアーキテクチャで紛れ込んだ欠陥の発見が、あとのフェーズで発見されるほど修正のコストは高くなる。

コンパクトにまとまっている。この本はコンストラクションをメインに扱う本だが、それでもコンストラクションの前の準備として、要求やアーキテクチャの話は欠かせないといった理由で扱っているのだろう。それほど大きなプロジェクトを一人で上流からコンストラクションまでこなしたことがないため、実感がわかないところでもある。正直、めんどくさい、という感想を抱いている。

## 2章を読んだ

メタファ

ソフトウェアを書く、というのはあまり良いメタファではないとしている。ソフトウェアは手紙を書くように書くのとはちょっと様子が異なる。人月の神話で使われたのが、普及したきっかけらしい。

アクリーション (accretion) というメタファもある。真珠。

ソフトウェアを構築するというメタファもある。建築との比較。

## 1章を読んだ

この本はソフトウェアコンストラクションの本だ。コンストラクションとはなにか、というと、大体はプログラミングのことだ。なぜコンストラクションという言葉に置き換えられているのか。ソフトウェア開発における各種のフェーズ、言い換えるとアクティビティにおいて、プログラミングというのは曖昧な表現になる。コンストラクションというのは、どうやらちゃんと定義があるらしい。そのちゃんとした定義の範囲での議論を行おうという意思が見て取れる。コンストラクションという聞き慣れない言葉で書かれているからと臆することはない。これはプログラミングのための本だ。さらに、タイトルが行っているように、コードが中心の本となっている。有意義な読書になるはずだ。

[ブクログ · ★★★★★]

私は、マコネルをまったく信用していませんでしたが、この本で私の認識が間違っていたことが分かりました。上流設計から、コーディング、マネジメントまで、ソフトウエア開発について、ここまで網羅した本は他にないでしょう。ほとんどの指摘は的を得ており、私は、９０％以上の彼の主張に賛成します。また、ほとんどのソフトウエアプロジェクトでは、ソースコードが唯一のドキュメントであるという言い切り方は、この人が現場での経験を充分積んだプロのプログラマーであることを証明しています。エンジニアは、先人の知恵に学ぶべきであり、この人は、学ぶに値する本当のプロです。ぜひ、この本（上下巻とも）を読むべきです。

[ブクログ · ★★★★★]

プログラミングでの命名規則を徹底検討

よりよいプログラミングを目指して書かれた書籍。分厚い。大量の文献が引用されており，読み応えが十分。
上下巻に分かれており，この上巻では主にプログラミングでの名前について解説されているのが印象的だった。

関数（ルーチン）の名前はどうすればいいか？変数名はどう書けばいいか？データ型やステートメントはどう使い分けるのがいいかなど，実際のプログラミングで誰しも一度は悩むような項目を扱っている。
たとえば，TotalDataとするか，DataTotalとしたほうがいいのか。

クリーンコードやリーダブルコードなど他のコーディングに関する本でもこうした項目に言及しているが，この本ほど網羅的で徹底的に議論されてはいない。おそらく，この本以上にコーディングについて徹底的に考察された本はないのではないかと思える内容だった。

p. 317の「11章 変数名の力」の冒頭の以下の言葉がこの本の本気度を伺わさせる。
「効果的なプログラミングにとって、よい名前というテーマは重要であるにもかかわらず、よい名前の作り方を10項目以上にわたって取り上げた本を読んだことはない。プログラミングに関する文献の多くは、省略形の選択に段落をいくつか割き、決まり文句でお茶を濁し、読者が自力で何とかやっていくことを期待する。本書はこれに真っ向から対抗し、良い名前に関する情報を使い切れないほど提供しようと考えている。」

値段は少々高いが，大量の文献，考察が書かれており，2005年出版とやや古いが，今でも通用するかなり有益な本だった。是非手元においておきたいと思える本だった。プログラミングするなら読んで損はしないと思う。

[ブクログ · ★★★★★]

読み応えのある本。

自分はこれでオブジェクトとは何か。
オブジェクトにおける振る舞いとは何か。
主にプログラミングインターフェースに関して、多くのことが学べたので非常に良かった。

[ブクログ · ★★★★★]

現場で生きるプログラマーの「教科書」。
学校で授業で習ってある程度プログラムを書いた後、あるいはプログラムを仕事である程度書いた後で読むのをお勧めする。
自分の今までの経験からも「あぁこれ書いた事あるわ」とか「これ見たことあるわ」というコードや問題が大量に出て来て苦笑するしかない。
今でも現場で記載されている問題は起き続けている。
現時点では多少異なる点はあるし、読むのにとても時間がかかる。
しかし是非とも現場で働く前に読んでおいていただきたい。

[ブクログ · ★★★★★]

全てのプログラマにとって有益な本と思います。この本に記された具体的なアドバイスに従うことこそ、高品質ソフトウェアへの一歩になるに違いありません。
なお、テストエンジニアは「第20章　ソフトウェアの品質」、「第22章　デベロッパーテスト」、「第23章　デバッグ」、「第27章　プログラムサイズが及ぼす影響」、「第30章　プログラミングツール」、「第34章　ソフトウェア職人気質とは」等々がある下巻の方が興味深く読み進めることができるかもしれません。

[ブクログ · ★★★★★]

本書は全てのプログラマーに捧げる、最高クラスの名著である。
ひとことで言うと、「コードスタイルとはどうあるべきか」を示した本である。ページは相当数あり、読み抜くだけでも相応の努力が必要だが、上下巻を読みきった頃にはソースコードに対する意識が変わっていることだろう。そしてきっとこう思うはずだ。「俺のコードは腐ってる」と。

[ブクログ · ★★★★★]

プログラマ志望の人にはぜひ読んで欲しい。
プログラマになってしまうと、仕事が忙しくて読む時間がない人が大勢います。
学生のうちに読んでおくのがいいかもしれません。

goto文論争など基本的な情報の資料にもなっています。
すでにプログラマになっている人は、C言語プログラマだけに限らず、多くの方が読まれているとよいと思います。
会社が、本当にプロを養成するつもりなら、必ず読めというと思います。
会社が、読む時間を工面してくれるはずです。

会社が、一時的な金儲けだけを目指している場合には読めと言われないかもしれません。
プロとしての仕事を目指すのではなく、顧客の対応の時間を重視しているなら、読む時間を工面してくれなかもしれません。

そういう場合は隠れて読んで、３年たったら別の会社に行くのがいいかもしれません。
いずれにしても、プロとしてプログラムに向き合う時に必要なことがいろいろ搭載されています。

ps.
最初は全部理解しようと肩肘はらずに、気軽に読み進んだ方がいいかもしれません。
仕事で関係がありそうな話題になったときに、もう一度読み直してみましょう。

[ブクログ · ★★★★★]

開発者必読の一冊。開発歴10年近いけど、それまでに培った以上のノウハウが詰まっていた。
技術の移り変わりは早いけど、あと10年は役立つ内容かと。

[ブクログ · ★★★★★]

ソフトウェア開発におけるベストプラクティスを網羅的に解説したプログラマにとってのバイブル的書籍である。
著者はソフトウェア工学の第一人者であるスティーブ・マコネルで、
私の会社の机にも置いてある「SWEBOK」の構築を主導している人物でもある。

この書籍が解説している範囲的は主に詳細設計?テストで、
上巻では詳細設計?プログラミングの部分を解説している。
この書籍の良いところは、かなり具体的に例を示している点で、
例えば、コーディングの際の擬似コード(PPP)のススメや、
変数の宣言、定義等のベストプラクティスなど、
実際の実務に直ぐにでも生かせるようなテクニックを惜しげもなく教えてくれる。
これは恐らく先人たちが何十年もかけて得た知識や経験を、
この本に凝縮して詰め込んでくれたのであろう。
そんな素晴らしい知識をたかだか数千円の投資で得ることが出来るというのは、
この著者に十分感謝しなければならないと思う。

以下、上巻を読んで大事だなと思った項目を一部抜粋します。
・プロトタイプを作成するときはクラス名やパッケージ名にprototypeというプレフィックスを付けるといった標準を設けるといい。
・設計書の文書化(CRCカード、UML、デジカメ、JavaDocの使用)。
・擬似コード (PPP)の活用。
・変数は宣言時に初期化する(C++など)。
・変数は最初に使用する場所の近くで初期化する。(VBなど)。
・変数の宣言と定義は、最初に使用する場所の近くで行うのが理想的である。
・できるだけfinalまたはconstを使用する。
・クラスのメンバデータはコンストラクタで初期化する。
・すべての変数を自動的に初期化するようにコンパイラを設定する。
・変数の参照はまとめて。
・トランプデータの削除。
・グローバル変数が必要なすべてのコードでアクセスルーチンを使用する。
・ロックを使ってグローバル変数へのアクセスを制御する。
・ループは一度に確認できる程度に短くする。
・ネストは3段階までに制限する。
・ブール値とtrue、falseは暗黙に照合する。
・ド・モルガンの定理を適用して、否定語のある論理評価を単純化。
・数値を含んでいる式は数直線の順番に並べる。
・Cでは、文字を終端のnull('\0')と明示的に比較する。
・Cから派生した言語では、定数を比較の左側に置く。(但し、数直線との関係が矛盾している)。
・null文の代わりにDoNothingプリプロセッサマクロやインライン関数を作成する。

[ブクログ · ★★★★★]

どの言語を使用していても役に立つ。これ一冊で得られるものは非常に多い。
プログラマがこれを読まない理由が思い当たらない。

[ブクログ · ★★★★★]

■概要
コードは書く事に費やす時間より
読むことに費やす時間のほうが長い

読みやすいコード（＝変更するときに間違えにくいコード）
を書くための色々なテクニックが紹介されている

割と基本的な事からしっかり書かれている

■感想

こんないい本を今まで読んでなかったなんて・・・と，衝撃を受けた
後１～２年早く読んでいれば卒業研究のプログラムなどがもっと効率よく書けたのに．

量は多いけど，栄養たっぷりで美味しいので
もりもり食べれた（本を食べ物に例えたメタファー）

ただ，全部消化しきったわけではないので
もっと経験を積んだ後に，また読み返したい1冊

我流でプログラムを勉強したが
読みやすいコードの書き方がいまいちわからない人や
これから，プログラムをもりもり書く人や
これから，チームでプログラムを書く人等に
おすすめの1冊

[ブクログ · ★★★★★]

手続き型言語を扱う全てのプログラマに無条件でオススメできる本。ある程度プログラムの経験を積んでくると、きれいなソースや効率化、再利用性といった物を求めると思いますが、その様な中級プログラマとして必須な考え方がぎっしりと詰まっています。デザパタ的なものではなく、モジュール強度や結合度的な考え方、変数やステートメントといったより細かい単位での考え方が詳しく載っているので、それらを人から習う機会が無かった人等には特にオススメです。
ただ設計の部分に関してだけは自分の肌には合いませんでしたが…。特にPPPの部分！いやそれはお前が分かってないだけだとか言われそうですけど（笑）
これを読むときっと「人に優しいプログラミング」ができるようになります。

[ブクログ · ★★★★★]

さぁ読め、今読め、全部読め。
その分厚さに怯んではいけません。
これなくしてコーディングは語れない。

[ブクログ · ★★★★☆]

昔仕事で読んだ本。業界ではよくある「より綺麗なプログラムを書く本」だ。この手の本は、数年に1回バズる印象を私は持っている。
この本はマイクロソフト公式を売りにしている。どこまで社内で活用されているかは分からないが、しっかりした内容はさすがあのソフトウェア"Windows"を作っているだけある、と思わせる構成。

一つ一つは深い話ではない。されど、それを組織で徹底して意識統一できるかが重要な気がしている。

上巻は基礎・高品質なコーディング・変数・ステートメント。

[ブクログ · ★★★★☆]

プログラミングを行う上で、おそらく熟達したプログラマーであれば自明であるような作法が丁寧に解説されている。
そして自明でありながら、最初からここに書かれていることを遵守したコードを書いていた、という人は少ないのではないか。

それぞれの現場で蓄積されたノウハウや事情が醸成するその現場のその時点では正しいもの。
ここでたびたび紹介される「怖いコード」は、そういったかつて正しかった・正しいと信じられていたものが風化した残骸なのだろう。

VBの例が頻出することからもわかるように、時代を感じさせる記述は多々ある。コードの読みやすさでいえばリーダブルコードだったり(これもいくぶん昔の本だが)、設計ならDDDやクリーンアーキテクチャだったり現代に即したものがいくつかある。

しかしコンピュータサイエンスの研究に根ざした網羅的な書籍として、依然本書はエンジニアの書庫に鎮座しておくべき存在だ。

[ブクログ · ★★★★☆]

書いてある内容はそう難しくない。わかってしまえば当然のことばかりだ。
が、その当然のことを知って（理解して）いるかいないかでは雲泥の差だ。
全体をざっくりでも把握して、たまに読み返していれば、日々のコードがきっと良くなる、そんな本。

[ブクログ · ★★★★☆]

言わずと知れたプログラミングの名著の上巻。
だそうなのだが、恥ずかしながら職業PG10年目にして購入。

本書はコンストラクション、つまり純粋なプログラム構築についてのプラクティスを中心においており、要求・仕様・設計・テストはあまり述べられない。

とはいっても要求が無ければプログラムを作ることはないし、
コーディングとはいっても、大小なりとも設計を伴うということで、
第一部を使って上流工程について述べられている。

サンプルコードはVisualBasic、C、C++、Java、そして疑似コードで記述されているが
いずれの場合も固有の記述法が関係する場合は説明がされているので、
読む分には好き嫌いする必要はないだろう。

全編にわたってとても優しく丁寧な文章で、楽しく読むことができた。
理解してしまえば、まるで「ネジは回せ、釘は打て」ってぐらい当たり前のことしか書いてないし、2005年にきちんと改版されているがそれでもちょっと物足りない感じもする。
恐らくこの本を読んでもできることが増えるというのは無いだろう。
しかしながら経験で身につけたものをきちんと整理するには良い本だ。
自分にとっては、経験から学んできたことが間違いでなかったことを確かめられて嬉しかった。

この業界の健全化のためにも、経験より先に学べても良いだろう。
初級者が初級者を卒業するために読んでほしい。
この本はとても優しい。

[ブクログ · ★★★★☆]

・PPPは仕様にもなるしコメントとしても利用出来るので便利。だがテスト駆動開発の方が捨てがたい。
・変数名で計算を表すのは最後が良い
・ブール変数はdone,error,found

[ブクログ · ★★★★☆]

ソフトウェアの設計に関する内容から始まり、プログラムを実際に書くときに気をつけることを、項目に分けて説明している。

プログラミングをし始めた頃は、何も考えずにプログラムを書いてしまう人が多いと思うが、それにブレーキをかけてくれる本がこれである。
最初に酷いソースコードを紹介し、その後に良いコードを示してくれるため、悪いコードと良いコードを知ることができる。
章の最後にはチェックリストがあるため、読み終わった後でも、このチェックリストを確認すれば、どのようなことに気をつければよいかを、簡潔に知ることができる。

最初の100ページくらいはソフトウェア設計について書かれている。
ソフトウェアを作り始めたばかりの人は、設計をあまりせずに、すぐにコーディングを行ってしまう人が多いと思うが、それが今後のソフトウェアの品質にどのように悪影響を及ぼすかを、教えてくれる。

分厚く、全部読むのにはそれなりの時間がかかってしまうが、プログラムを書き始めてしばらく経った人は、ぜひ読んで欲しい本である。
私はこの本を読み、ソフトウェアの設計をする事が重要であることを知り、自分が書いていたソースコードの問題点を再確認することができた。
あえて欠点を挙げるとすれば、本が厚く読むのにちょっと時間がかかると言うことだろうか。
もう少し、コンパクトにしてもらえたらよかったなと思う。

[ブクログ · ★★★★☆]

プログラマーの必読書

変数名、制御構造などの幅広いことを詳しく解説しているので、この本を読むことによって、どのようなプログラミングをすればいいのかがよくわかるようになる。

プログラミングし始めてから、1年ぐらいに読むのがオススメ

[ブクログ · ★★★★☆]

すぐれたプログラミングとはどのようなものか論理的かつ明快に書かれており、かつ具体的なコードが裏付けをもって書かれている。
文法は覚えてなんとか書き始めたものの、その先を超えたノウハウ、実践的な知識を得られる貴重な本。
この上巻は直接コードを書くためのノウハウが詰め込まれている。

[ブクログ · ★★★☆☆]

強制的に読まされた(笑)書籍
分厚さに圧倒されるがこれでまだ上巻
書いてることはもっともで読んで損はないと思う。
もう少ししたらもう一回くらい見直したい

[ブクログ · ★★★☆☆]

説明しなくてもわかるじゃんと思うようなことについて理路整然と根拠が書かれているので職場のわからず屋を説得するのにいい材料になります。