スケジュールに追われ、後回しにされがちなコードの品質。
テスト工程で障害を無くしていくのも品質改善の一つですが、プログラムの修正や機能追加などで誰が触るかわからないコードを綺麗にするのは結構大事な事かもしれません。
綺麗に書けば、最終的に障害対応もやりやすくなるはずです。
すぐに実践できるものをまとめてみました。
構成
コーディング規約に従う
適切な変数名
参照する変数は近づける
不変な変数は定数に
共通化
ネストを減らす
コーディング規約に従う
プロジェクトには必ずと言っていいほどコーディング規約のようなものが用意されています。
これに従うのが結局一番品質が良くなると思います。プロジェクト内で書き方が統一されていれば保守がしやすくなります。
これから説明することよりまずは、プロジェクトのコーディング規約に従えばOKだと思います。
適切な変数名
当たり前ですが、何が入っているかわかる変数名にしましょう。
基本的に変数は主語で、関数名は動詞で命名します。
プロジェクトのコーディング規約に命名規則があれば、それに従います。
私は変数名を考えるのが苦手で嫌いです。なので下記サイトをよく利用します。Googleで「it 変数名」と検索すると一番上に出てきます。
参照する変数は近づける
たまにプログラムの最初にまとめて変数を宣言しているプログラムを見ることがあります。
参照している処理まで辿り着いた時、この変数何が入ってるんだっけ？と一瞬考えてしまいます。
これは読む人にとって負担だと思います。上までスクロールするの面倒臭いです。
const hoge = "hoge";
let fuga = "fuga";
let fugafuga = "fugafuga";
//処理
//処理
//処理
//処理
//処理
if (fuga) {
//処理
}
距離を近づけるだけで、読む方も楽になります。共通で使う場合でも、出来るだけ近くに宣言するとギュッとなって見やすくなると思います。
let fuga = "fuga";
if (fuga) {
//処理
}
不変な変数は定数に
変数の宣言時に変わらないことがわかっているのであれば、定数にしましょう。
他の誰かが見た時に、途中の処理で書き換えが発生していないか確認しないといけなくなります。
時間の無駄です。
var hoge = document.getElementById('fuga');
// 処理
// 処理
// 処理
// 処理
// 処理
// 処理
checkHoge(hoge);
const hoge = document.getElementById('fuga');
// 処理
// 処理
// 処理
// 処理
// 処理
// 処理
checkHoge(hoge);
共通化
同じような処理は共通化してしまいましょう。
これもすぐに出来る品質改善ですね。
変数化
複数回同じ処理を書いていると、その部分の処理に変更が必要になった時に修正が面倒くさいです。1文が長いので可読性も微妙です。
function hoge(val) {
if (val === document.getElementById("hoge").value) {
console.log(document.getElementById("hoge").value);
}
}
変数にまとめまてしまえば、修正箇所も減り読みやすくもなります。
function hoge(val) {
const hogeVal = document.getElementById("hoge").value;
if (val === hogeVal) {
console.log(hogeVal);
}
}
関数化
同じ処理何回も書いてるなと思ったら関数として切り出してみてください。すっきりするかもしれません。
下記は例として現在日付を文字列で取得する関数を共通関数として定義しています。
function check1() {
const strNowYmd = getStrNowYmd();
// 処理
}
function check2() {
const strNowYmd = getStrNowYmd();
// 処理
}
function getStrNowYmd() {
const dt = new Date();
const y = dt.getFullYear();
const m = ("00" + (dt.getMonth()+1)).slice(-2);
const d = ("00" + dt.getDate()).slice(-2);
return y + "/" + m + "/" + d;
}
ただし、便利にし過ぎようと様々なところから使えるような関数を作ってしまうと逆に保守が大変になってしまうかもしれません。呼び出し元によって処理を分岐したり特定の呼び出し元でのみしか使わない処理が出来上がってしまうことで複雑化し、修正が大変になります。呼び出す側の影響も考慮し、慎重に修正しなければいけません。
上記例のような明らか汎用的なものはガンガン共通化して良いですが、業務的な処理は仕様変更も考慮し判断すると良いと思います。
ネストを減らす
現場レベルだと、条件分岐などでカッコが大変なことになることがあります。
if (条件1) {
if (条件2) {
if (条件3) {
// 処理
}
}
}
改善方法としては下記があると思います。
- 複合条件
- 早期リターン
- 条件を関数化する
複合条件
複合条件にすることで、ネストを簡単に削減できます。
ただ、条件が増えたり複雑だと可読性を考慮して別の手を考えることになりそうです。
if (val === "hoge" && val2 === "fuga") {
// 処理
}
早期リターン
これも一つの方法ですね。
条件に当てはまらないものは早めにリターンすることで、ネストを削減できます。
if (!val) {
return;
}
if (val !== "hoge") {
return;
}
// 処理
条件を関数化する
条件が複雑でifに直接書きづらかったり、ネストが多くなってしまいそうなら関数化してしまうのも１つの方法です。
if (isChecked(val)) {
// 処理
}
function isChecked(val) {
return 条件
}
最後に
プログラミングって最初は動いて感動します。満足します。
学んでしばらく年数経つと、動くだけでなく綺麗さを求めるようになります。
正解が無い部分でかなりの時間を要してしまうので、自分にイライラします。
この時間も勉強だと思って、いつかはスラスラと思いやりのあるプログラムが書けると良いなと思います。