リーダブルなコードを書く際に気をつけていること
プログラミング #クリーンコード #リーダブルコード
目次 / Index
はじめに
プログラミングする時、状況にもよりますが、体感的にはコードを書くよりも読む時間のほうが多いように感じます。
実際調べて見ると、裏付けるような記事が散見されますので、あながち間違いではないのかもしれません。
読む時間のほうが長いのであれば、コードが読みやすければそれだけ開発速度も上がりますし、わかりやすいコードはバグの発生抑止にも繋がります。
リーダブルなコードはとても価値のあるものなので、面倒くさがらず目指していきたいですね。
リーダブルにコードを書く必要性
「はじめに」でも少し言及しましたが、主に以下のメリットがあると考えています。
1. メンテナンス性の向上
- リーダブルなコードは他の開発者や将来の自分自身にとって理解しやすい。
- コードの保守や機能追加に要する時間と労力を減らすことが可能。
2. バグの減少
- 読みやすいコードは、ロジックの誤りや潜在的なバグを発見しやすくなる。
- コードレビューの効果が高まり、品質の高いソフトウェアを開発可能。
3. チームの生産性と士気への悪い影響を防ぐ
- 意欲の高いエンジニアは、成長出来る環境を求める傾向にあるため、読みにくいコードだらけで自身の実力が上手く発揮できなかったり、実力が落ちてしまいそうと感じると最悪プロジェクトを離れてしまい、品質の低下や生産性が落ちる可能性がある。
リーダブルなコードを書くには
以下、私が気をつけている点を3点紹介します。
1. 本の見出しとなるようなメソッドの分割と命名にする
例を踏まえてご紹介します。
例えば、以下のようなサイドバーメニューの開閉(ドロップダウンメニューも内包)を処理するjsがあったとします。
こちら一見した限りでは、何をしているのかわからなく、それぞれコードを読み解いていかないといけません。
まだ、こちらは処理も少なく、そこまで問題とはならないかもしれませんが、同じような形でひたすら処理だけ書いてあるコードを想像すると大変ですね。
$(function () {
const $sidebarWrapper = $('#js-sidebar-wrapper');
const $dropdown = $('.js-sidebar-dropdown');
$('#js-sidebar-close-btn').click(function () {
$sidebarWrapper.removeClass('toggled');
})
$('#js-sidebar-open-btn').click(function () {
$sidebarWrapper.addClass('toggled');
})
if (window.matchMedia('(max-width: 599px)').matches) {
$sidebarWrapper.removeClass('toggled');
}
$dropdown.find('> a').click(function () {
const $clickedDropdown = $(this).parent();
if ($clickedDropdown.hasClass('active')) {
$clickedDropdown.removeClass('active');
} else {
$dropdown.removeClass('active');
$('.js-sidebar-dropdown-menu').slideDown();
$clickedDropdown.addClass('active');
$clickedDropdown.find('.js-sidebar-dropdown-menu').slideUp();
}
})
})こちら、メソッドを分割し、見出しになるようなメソッドの命名をすると以下となります。
$(() => {
const $sidebarWrapper = $('#js-sidebar-wrapper');
const $dropdown = $('.js-sidebar-dropdown');
const $dropdownMenu = $('.js-sidebar-dropdown-menu');
const toggleSidebar = isOpen => $sidebarWrapper.toggleClass('toggled', isOpen);
const closeCurrentlyOpenedDropdown = () => {
$dropdown.removeClass('active');
$dropdownMenu.slideDown();
};
const toggleDropdown = $clickedDropdown => {
const isActive = $clickedDropdown.hasClass('active');
if (isActive) {
$clickedDropdown.removeClass('active');
} else {
closeCurrentlyOpenedDropdown();
$clickedDropdown.addClass('active');
$clickedDropdown.find($dropdownMenu).slideUp();
}
};
const initSidebarToggle = () => {
$('#js-sidebar-close-btn').on('click', () => toggleSidebar(false));
$('#js-sidebar-open-btn').on('click', () => toggleSidebar(true));
};
const initDropdownToggle = () => {
$dropdown.find('> a').on('click', function() {
toggleDropdown($(this).parent());
});
};
const hideSidebarOnMobileView = () => {
if (window.matchMedia('(max-width: 599px)').matches) {
toggleSidebar(false);
}
};
initSidebarToggle();
initDropdownToggle();
hideSidebarOnMobileView();
});少しコード量が増えますが、メソッド呼び出し箇所を見れば、このjsではどういった処理が行われているのか一覧で簡単に見ることが出来ます。
そのため、修正が必要な箇所をすぐに見つけることが可能となり、また、変更が不要な箇所かどうかの判断もすぐに出来るため、不要に処理を追う時間を削減できます。
2. なぜ？を説明するコメントを書く
基本的には、しっかりした命名や分割が出来ていれば、コードの動作を説明するコメントは不要になります。
コメントはコードがわかりにくいから書くというのではなく、背景が推測出来ない場合に書くようにします。
コードを見て、「なぜこういう処理をしているんだろう？と疑問が出そう、かつ、コードを見ただけでは疑問を解消出来なそう」と思ったらコメントを書くというのがシンプルな基準で良いと思います。
現在実装している自身が持っている知識は、数年後には忘れていると思います。この数年後の自分が見て、疑問に思わないか？また、コードだけで疑問を解消できるか？という視点を持つと必要なコメントを書けるようになっていくと思います。
3. テストしやすいよう疎結合なコードを書く
テストがあるとコードの理解やデグレ防止に役立ちます。そのため、テストがしやすい設計だとリーダブルなコードに間接的に繋がります。
テストがしやすい設計とは、疎結合・高凝集で関心が閉じており、DIを活用し他の処理への依存がない状態を指します。
こうすることで、他の処理部分はスタブとし、自身の処理だけをテストすることが可能となり、結果、テストがしやすくなります。
コードを書く時は、テストがしやすい設計か？という観点を持つと良いかもしれません。
最後に
今回、制御フローを読みやすくするなどの話題は今回割愛しました。
理由は一般的にリーダブルコードと検索するとたくさんの記事が出てくるのでそちらでカバー出来るのと、この辺の話は基本Linterを入れていれば、そもそも警告されてCIで検知出来るので問題ないかなと考えたためです。
リーダブルなコードを意識して、保守性の高いコードを書いていきたいですね。
