なんとかなるこれぷしー

眠りは僕の親戚だ

リーダブルコードを読んでみた

 こんにちは。半社内ニート状態の僕です。

 

 今は次の仕事が決まるまでだいたい放置な感じなので、こうやってブログを書いたり

paizaでスキルチェックしたり、本読んで勉強したりしてます。

 

本は割といろいろと読み漁っているのですが、特にプログラムに関する技術書はどこかでアウトプットしたり実践してみないことには身にならないなと思いました。

 

なので文章の練習やアウトプットもかねてこうやってブログを書きだしているわけだけど、なかなか本題に移るのって難しいですね。(書きながら構想を練っているふりをしているのです)

 

僕はこういった技術書の内容を整理する場合、頭の中で読む前の自分に教えるシミュレーションを脳内で行います。脳内で完結してしまうので、ふわっとしたところがあり理解度もあやふやなのですが、自分の理解していない部分がわかっていいような気がしてます。

 

そしてそれを今回はブログで実際に書くことによって更なる精度が求められ効果は倍増するのではないかと思います。

 

ではでは

 

今回読んだ本はこれ↓↓

 

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

 

 

はい。実際に開発する機会があるエンジニアはなんかしらのルートで出会う本です。

 

この本は読むことによって自分のためにも相手(チーム)のためにもなると思います。プログラミングの基本的な作法が一通り学べます。

OJTで現場でコードを書く機会はありその過程でプログラムの書き方は学べますが、同じ振る舞いをするコードでも変数やメソッドの命名の仕方やインデントのつけ方はなかなか学べません。また、現場によってルールが少しずつ違っている場合が多々あると思います。

 

僕は独学しているときはEclipseでコードを書いていて基本ctrl + shift + Fでオートフォーマットしていたのでインデントは気にしたことはありませんでした。

しかしある現場でsakuraエディタでSQLを書くことになりそこでインデントを合わせるのに苦労しました。普段意識していなかったことなので習慣がついておらず、他と違う合わせろとたびたび怒られました。僕はここで初めて見た目って大事なんだなと気づきました。今まではコードは自分の中で完結していたので他人がどう思うかなんて考えていませんでした。

しかし現場では必ずと言っていいほど他人とコードを共有するし、出来上がったコードは提出する商品となるわけなので意識を変えていかないなと思いました。

その後も変数のつけ方やコメントのつけ方も俺ルールで書いていたのでけちょんけちょんに言われてものすごくへこんだのを覚えています。

一応その場でチャチャッと教えてくれるのですが知っていて当たり前でしょ?という体で言われるので1から10まで丁寧に教えてくれるわけではありませんでした。なので全体像が見えずもやもやしていました。

かなり脱線しましたがこのリーダブルコードは1から10まで丁寧に教えてくれるので大変助かりました。完全には理解できていないのでなにかまたこの手の壁にぶち当たったときにサッと読み直せるよう手元に置いておきたい一冊です。

今思い返してみれば僕に注意してくれた人もこの本の内容を前提にして話していたのではないかと思います。

僕は本当に勉強不足でした。コードのお作法なんて一番後回しでいいやというくらいの意識だったので反省してます。

 

やっと内容の方に移れますが、コードが壊滅的だったあの頃の僕に教えてあげられることは以下ののシンプルな解です。

 

・コードは誰が見てもわかりやすいように。一般的なルールに則って書こう。

仕事でコードを書く場合は他人が見るので当然。また自分ひとりで書く場合も、明日の自分は他人です。他人にも自分にも思いやりを。

 

・関数や変数名はそれがどのような振る舞いをするのかわかる名前を付けよう。

これはある種のセンスだけど良いのが思いつかないからと言ってその日の昼ごはんのメニューなんかをつけちゃあだめだぞ絶対。それに小説や物語なんかでも登場人物は暗にその人がどんな人か表していたりするでしょう。切り裂きジャックはあ、こいつ切り裂くなってなんとなくわかるしメインヒロインでもないなって分かるし。下手でもいいから伝わる名前を付けよう。長くなってもideやエディタは予測変換などで出してくれるから臆するな。

 

・一行ですべてを詰め込もうとしない

一行のコードでより多くの仕事を詰め込むことがかっこいいと思っているね?でもねそれは往々にして読み返したり初めて読む人にとっては理解に時間がかかってしまうんだよ。この時間は無駄だね。やめよう。ただ無駄に細切れにして意味のない変数をやたらと宣言するのもそれはそれで混乱するので、気を付けて。

 

・読んでわかることをわざわざコメントで書かない。コードの説明をしやすくなるようなコメントを添えよう

変数の横にわざわざなんの変数なのか説明するのはナンセンスだね。命名するときに理解できるように考えれば済むことだね。どうしても分かりづらいと判断した場合はコード説明コメントの時に言及しよう。また、コメントはブロック毎に書いていこう。

 

・if文のネストは深くなり過ぎなくなるようがんばろう。

ネストが深くなると自分でもどんな動きをするか自分でもわからなくなって、勘でデバックしていることがあるね。自分でもわからないコードが他人に分かるはずがないので外に出せるものはだしてすっきりさせよう。お互いのために。その方がバグも減るしコーディングの時間が結果的に短縮するはずだ。

 

最低限いえるのはこれぐらい。

リーダブルコードではこれはほんの序の口でもっと具体的に深く示唆的なことが書かれていたけれど。まだまだピンと来ていない部分もあるのでその時になったら読み直そうと思います。

とりあえず今は上で上げたことを常に意識して実践する。

 

今日はここまで