リーダブルコードRTA =1日目=

IT
スポンサーリンク

~目的~

以下のURLからご確認ください 。
https://amefura.com/readable-code-000/

~進捗報告~

槍の勇者のやり直しを読んでいたせいで、更新の遅れたリーダブルコードRTA(Rakuni Tanoshiku Asonndemiyou)はっじまるよー。

本編よりも長い外伝とはいったい……。
ある意味小説家になろうらしい本でだな……。そういう現代らしさも楽しめるからなろうも結構好き。

本書におけるページ

  • 9ページから110ページ

ここまでうわっと眺めての感想

  • †正しいソースコード†とはこのことか……(くそいきり)
  • 第三者が読んでもわかりやすくするとは?

われは正しきソースコードを学びしもの……。
そこらの下民とは格の違う生き物ですぞよ……(読書時間結構短い)

はい。実際2時間……3時間……ああ……どのくらいかよくわかんないですね。
実際このブログ○○日目といっている割にクソ適当なナンバリングですし。
今回も暇つぶしに偶に読んでいただけなので……。

でもこの本を読む前とあとで結構意識が変わりました。

基本的に一人でプログラムを書いているときにはコメントとかつける気なかったですし……。
いままで書いたものも大抵、300行いって、『お。割と書いてんなー』ぐらいの気持ちでしたから……コメントつけなくてもわかっちゃうんですよねえ……。

まあ、読んでて感動的に感じた手法は次の項目でまとめるんで。
そっちに具体的な話を書いていきますね。

~読んでて感動したこと~

いつもはここに詰まったこととか書くのですけど読み物主体ですからねえ。むしろ読んだ内容を忘れないようにメモを取る方が重要そう。
というわけでメモですメモ。

ループイテレータ

for(int i=0; i<x; i++){~~~~~}

とかのやつですね。この『i』と『j』です。
このiやjは、配列のような数字が変化すると値が変わるものとセットに使ったりします。この時のiとjをその配列と対応した名前にすると、バグがわかりやすいというものです。

例えば処理でif (members[i]==users[j])を、if (members[mi]==users[uj])にできるのでわかりやすくなるそうです。
この時に間違ってループイテレータを反対にしているとif (members[uj]==users[mi])になるため、明らかに先頭の文字が違います。

いやー……。もっと早く知っておきたかった。

(本書14ページから具体例の引用)

正しい英語の重要性

これは全体を通して言えることなのですが、正しい英語はどうやら必須のようです。

ITエンジニアの方で英語が苦手な方。いらっしゃいますよね? 奇遇ですね。僕もです。
『まあ、最低限の内容は日本語になってるし、必要なら頑張って読むし大丈夫だあー』と僕は思っていたのですが、書きも必要のようですね。はい。

なぜこんなことを言うのかというと、簡単で使いやすい単語を使うとあとから見た時に何が何なのかわからなくなるからです。

例えばfilter。これを関数名にしたとします。

しかしこれでは何をどうやってフィルターするのかわかりません。
対象は数字なのか、文字なのか。フィルターのかけ方は『xxのみ』なのか、『xxを除く』なのか……。

『xxのみ』なら選択としてselect、『xxを除く』ならば除外としてexcludeにすべき……らしいです。
(本書30ページから具体例の引用)

このように様々な単語で変数や関数を彩る必要があります。
そしてこれは多くの章で共通して言われています。
名前は最短のコメントなのです。

2章と3章ではこんな感じのことが書いてありました。

コメントすべきでないこと

『コメントすべきでないこと』というのは初めて聞く概念でした。

どうやらコメントしなくても良いどころか、あったらむしろ邪魔な場面があるそうです。
つまり、class Account {~~}とあるところにわざわざ『// Accountクラス』とは書かなくてよいということです。
(本書57ページから具体例の引用)

まあ、つける必要が無いのは当然ですよね、じゃあ、どうしてつける必要が無いのか。
それは『新しい情報を提供していないから』だそうです。
ただソースコードが長くなっただけ。
書く方も手間ですし読むほうも手間です。
書かない方が良いようです。

当たり前じゃんといられそうですが、昔似たようなことをやってしまったおぼえがあります。というかやってました。
コメントはつけた方が良いという言葉を安直考え、メソッドの前全部にコメントをつけていました……。懐かしいなあ……あのJavaのプログラムどこ行ったんだろ?

そして『新しい情報を提供していないから』はさらに形を変えて話に登場するようです。コメントは短く、かつ、あたらしい情報を詰め込む。
そのために簡単な具体例を書いたり、『キャッシュ層』や『正規化』のような言葉を正しく使うことも重要なようです。

ここら辺は5章と6章の内容です。

~明日の目標~

なんか明日には終わりそうですね。ためにはなるのですが、いかんせん薄いなあ。いや長い方がルールを把握できなくなりそうだし短い方が良いか……。

でもアプリケーションエンジニアのバイブルと聞くし、良いことが沢山書いているので買ったのは正解のような気がします。

それにこれ、あれですね。チームで使うとしたら全員読んだ方が良いですね。一人がこのルールを気にして書いてくれたとしても他のメンバが気にしていなければ、誰も気づかないかもしれません。

よーし。立派な社畜に加工されるために明日も頑張るぞー(白目)

~リンク~

前⇒ https://amefura.com/readable-code-000/
次⇒

初めから⇒ https://amefura.com/readable-code-000/

タイトルとURLをコピーしました