WGC1 第1章 1.4グレートコードを特徴付けもの


「基礎が大事」という本当の意味を理解しているか?
はい、理解してなかったです。
1から基礎の勉強をやりなおします。
無意識でこなせるようになるまで。



まずは、仕事で使っている割合としては9割りであるC言語の基礎をやり直す。
(最近はコードを書かずに、トラブル調査ばかりだけど。)
参考書は、『Write Great Code〈Vol.1〉ハードウェアを知り、ソフトウェアを書く』だ。


まずは、Great Codeとは?
第1章 グレートコードを書くために知っておくべきこと
1.4グレートコードを特徴付けもの

1)CPUを効率的に使用する(つまり、コードが高速である)
2)メモリを効率的に使用する(つまり、コードが小さい)
3)システムリソースを効率的に使用する
4)可読性に優れ、メンテナンスが簡単である
5)一貫したスタイル指針に従う
6)ソフトウェア工学的に確立された規約に基づいて系統的に設計されている
7)拡張性に富む
8)十分テストされ、堅牢である(つまり、確実に機能する)
9)ドキュメントが整備されている

書籍には、番号は振ってないが便宜上番号を振った。

1)と2)は、4)と5)と矛盾することもあると思う。1)、2)を優先するために
トリッキーなことをしたりすることもあるのではないだろうか?
それを契機に一貫性がなくなってしまう場合もあるかと。
そして4)、5)が一度崩れ始めると歯止めが効かず、8)が危うくなっていく。


1)、2)でトリッキーなコードでもコメントを書いてくれてればいいんだけどね。
それが意図したものなのかバグなのか判断につかないものが多々ある。


つまり、9)だね。フローチャートみたいなものはいらない。全体像や全体のシーケンスと
APIの仕様書と実装した理由、設計思想がわかればいい。
コードの中で、XXXXというAPIを呼び出してるに。XXXXするというは意味がないからやめる
ようにしている。
僕も実装するときに自分の考えをまとめるときに書いてしまうのだけれども。
「英語でコメントを書く」と仮定として、API名をバラしたようなコメントしか
思いつかない場合は、書かないことにしてる。
あまりに長文で英語で書けないような場合も、なにか設計がおかしいのだろうと
考えるようにしている。




とグダグダ言わずにGreat Codeを書けるようになればいいのだ!!











Randall Hyde、鵜飼 文敏、まつもと ゆきひろ、後藤 正徳、トップスタジオ