【開発哲学3_31】〜『CODE COMPLETE第２版 第31章(下巻)』の感想〜レイアウトとスタイル
いよいよ最終部
第7部「ソフトウェア職人気質とは」
に入った〜〜〜〜🕺
感想
章題だけ見ると、操作画面とかインターフェース、DBなどのレイアウトとか文字のスタイル
デザインについて書かれてる
ように一見思えるけど、そこはあくまでもコードコンプリート。
コードを書くプログラマが、エキストエディタ上で、
＜どうコードを書けば、より洗練されたコードの書き方ができるか＞
＝良くない書き方はどんなものか
を丹念に書いている章。
正直、この章は、クヌース博士の文芸的プログラミング
やこれまでに出てきたリファクタリングなどの全般に通じる話。
特に、
独学で本やネットでサンプルコードを見ながら勉強したことがあるけど、
他の人が実際に書いた汚いコードを見たことがない。「コードなんて動けばどれも一緒だし、どんな読みにくいコードも理解するのが職人だろ！」と思って、変な癖がついてる。
人にはオススメな章
ここでとやかく書くよりも、この章で実際に、
＜読みにくいコードとは何か＞
に触れて常にコードを書く際に意識しておくと、
バグが少なく、変更しやすいコードが自然と身につくかなあ
て感じ。
悪いコードがどんなものかを知らないと、
本で書いてたからと、あえて読みにくいコードを書こうとする。
他の人はあえてやっていない悪いコードの書き方なのに、独自スタイルを勝手に作って、変な癖がつく。
てことになるし。
そうなってから、いざどこかの現場で仕事をすると、他から顰蹙を買うことになるから気をつけよう。
P.327
のMartin Fowlerの格言どおり！！！
（もちろん、自分ができているとは思わないけど）
詳細
見出しとしては、
レイアウトの基本
レイアウトテクニック
レイアウトスタイル
制御構造のレイアウト
ステートメントのレイアウト
コメントのレイアウト
ルーチンのレイアウト
クラスのレイアウト
参考資料
まとめ
て感じ。
そういえば前の現場（VBA）にいた多くの人で、
全てのコードの間に空白行を入れて改行はしてたんだけど、
ステートメントの中身の改行の仕方が壊滅的に悪く、
コード全体がただでさえ長いのに、
ルーチンを小分けにしておらず、
画面枠に縦にも横にも収まりきらないコードばかりだったな💦
（コーディング規約自体がない職場だったのに、なんで？）
結局、そのコードを数ヶ月前に書いた本人が、コード解析だけでもすごく時間がかかって改修がギリギリになってたな。
で、また不要な改行入れてるし。
この章に書いている
どれかひとつの方法だけを取り入れれば良いわけじゃない
ってゆー良い反面教師✨
（その前から個人的には、この本読んでそんなことは知ってた上で、現場で経験も積んでたからやらずに済んでるんだけど。）
コーディング規約がない職場って
個人個人のコーディングスタイルとか美的感覚の違いで諍いになったり、人間関係がギスギスしたりが多かったなあ。
職場の陰のあだ名が Mr.バグって人もいたし、、、💦
（自分も陰で言われてるんじゃないかってビクビクしてたわ）
まとめ
💃結局は、個人個人の美的感覚＝主観
だけど、そこを統一しておくことがチーム作業では大事🕺
（だから普通は、コーディング規約とか作ってるんだけど）
↓
ひとつのやり方に固執しない
この記事が気に入ったらサポートをしてみませんか？