ホーム

スタッフブログ

2021年1月13日

プログラマーは(デザイナーも)読むべき、”リーダブルコード”について

こんにちは、
プログラムチームのKです。

ただいま絶賛プログラムのルールや知識を蓄えている途中なのですが、
その中でものすごく勉強になった本を紹介しようと思います。

それがこの”リーダブルコード”です。

プログラムチームの上司であるAに直々に進められて読み始めましたが、
気づかされることがいろいろありましたので、
書き残そうと思います。

プログラマだけでなく、CSSやJSを触るデザイナーにも
ぜひ読んでほしい内容です。

リーダブルコードでは、

主に「良いコードを書く」をテーマに

「良いコードと悪いコードの例」
「良いコードを書くためのポイント」
「そのコードがなぜ読みやすいか」
が記述されていて、とてもわかりやすく、納得させられる内容ばかりでした。

良いコードとは

例えば
良いコードってどういうもの?と聞かれた時に

「コードが少ない」

とか

「無駄なコードがない」

とか

よく挙げられると思います。

しかし、リーダブルコードでは、
コードの読みやすさの定義を

他の人が処理を最短時間で理解できるコード

としています。

だから、「短い」や「無駄がない」は
必ずしも、「読みやすい」コードではありません。

ソースコードは、誰が読むかわかりません。
不具合や仕様変更があれば、自分以外のプログラマがそのコードを読むことだってあります。

だからこそその人が最短時間で理解できるコードを書くことが重要です。

その名前は意味が通じるのか

クラス名、メソッド名が抽象的

よくある事です。自分も思い当たります。

例えば、
データベースからデータを取得するというメソッドに対し、
getDataと命名したとします。

一見シンプルでいいではないか、と思いますが、
リーダブルコードに言わせてみれば曖昧です。

一覧情報のように複数件取得するのか?
それとも、データの更新用に一件のみ取得するのか?
そもそも何のデータを取得するかも解りません。

名前が曖昧だとそのメソッドや変数が、
何の役割を持っているか解らないので、

そのメソッドの処理をきちんと確認するという
無駄な時間を使うことになります。

チームで書き方を統一する

一番わかりやすい例はマジックナンバーです。

値によって区別したいときに、自分で値を定義して
「1だったら…、2だったら…」
という制御をかけてしまうやり方です。

マジックナンバーを使うと、その意味をコメントに残さないと
「どのような制御を行なっているのか?」
が解りません。

他の人と書き方を統一することで、
初めて見るコードでも処理の流れが同じになり、読みやすくなります。

また、インデントの縦軸を意識して、
しっかり揃えることをも大切です。

本当に必要なコメントを書く

自分的にはこの内容が一番刺さりました。

「意味のないコメントは避ける」

せっかくコードを綺麗に書いても、
コメントだらけのコードは可読性を下げる要因になります。

「自分がやりたいことが書かれていないコメント」
「処理の仕組みを説明しているコメント」
は良くありません。

では、なぜ良くないのか?

理由は、処理結果が正しいのか判断できないためです。

作成者が「どのように考えて処理を作ったのか」理解できれば、

・ロジックが間違っているか?
・やりたい事が違うか?

が判断できます。

これは、共通処理などで不特定多数の人が扱う場合は特に重要です。

共通処理ではなくても、「自分以外の人を意識する」は大前提です。

おわりに

「良いコードを書くこと」は、
簡単そうに見えますが意外と難しいです。

リーダブルコードを読んでからはさらに難しく感じます

「本当にこのメソッド名でいいのか?」
「他の人が読んでわかるのか?」

考えることは増えましたが、
日頃から意識して取り組むことで身につくと思います。

求人バナー

このページの上部へ戻る