Blogブログ

プログラムを書く時に意識していること

エンジニアの梶原です。
「年取ると調子いい時の方が珍しいよ」と誰かが言ってましたが、最近身に染みて実感しております。
FF5のオールドのデバフってこんな感じなんでしょうね。

そんなオールドタイプの私は、今まで色んな人の色んなソースコードを見てきました。
ソースコードって人柄が出ると思いません?

キザな人
斜に構えた人
回りくどい人
無駄がない人

最初は動くことだけしか考える余裕ないかもしれませんが、ずっとそのままだとやばいです。
というのも、プログラムを書けば書くほど、良いコードが書けるとは限らないんです。
常に意識しないと酷いコードになるんです。

昔の自分のコードを見てみてください。
どうですか?汚いと感じるようなら、あなたは成長してるんです。
と言うわけで、自分が普段意識していることをお伝えしてみようと思います。

変数名、関数名はわかりやすく

function myFunc(num, num2) {
  let a = 1;
  for (let num3 = 0; num3 < num2; num3++) {
    a *= num;
  }
  return a;
}

累乗の計算ですが関数、変数に意味がないので読むのに苦労します。

function pow(base, exponent) {
  let result = 1;
  for (let i = 0; i < exponent; i++) {
    result *= base;
  }
  return result;
}

同じ処理ですが、意図が伝わりやすくなったのではないでしょうか?
そもそも累乗の計算はMath.pow()というのがあるので、そっちを使いましょう。
これを使えば実現できそう。という引き出しは経験によって培われる大事な要素ですね。

同じことを書かない

DRY原則(Don’t repeat yourself)とか言われてたりします。
同じことを何度も書くと変更があった時大変だよねって話ですね。

ただし、これがいきすぎると逆に見づらくなったりもするので、全く同じ処理の塊を見つけたら関数化。あるいは「これは簡単に処理が共通化できそう!」という似た処理の場合は共通の関数化してみる。ぐらいに止めるといいと思います。

関数内の処理は粒度を揃える

function init()
{
  let a = 0;
  let b = 0;
  let c = init_c();
  let d = array();
  
  for () {
    // dの初期化
  }

  //ごりごりのビジネスロジック

  if( 複雑な判定 ) {
    // ごりごりなビジネスロジック
  }

  // UI操作系処理などなど
}

変数名適当なのはご容赦を

色々初期化する関数だな。と読み進めていくと
c は初期化関数で初期化しているのに、dはここで直接初期化している。
d も初期化関数作った方が読みやすくなりそう。

初期化する関数かと思いきや、いきなりビジネスロジックが入ったり、複雑な判定が入ったり。
初期化の中ですべきかを検討し、可能であれば、このinit()を読んだ後に実行すべき処理です。

複雑な判定も、何行にもわたる難解なifは、関数化すればいいです。

粒度が揃ってない関数は、目次読んでるつもりがいきなり本文が差し込まれてるような違和感とストレスを感じるものです。

書き方を統一する

同じことをしたくてもいくつもやり方があったりすると思います。
書き方を予め統一しておくことで、スラスラ読めるようになります。
わかりやすい例でいくと

PHPの配列処理
// どちらも同じ意味
$fruits = array(‘りんご’, ‘ぶどう’, ‘バナナ’);
$fruits = [‘りんご’, ‘ぶどう’, ‘バナナ’];
配列の末尾に追加
// どちらも同じ意味
array_push($fruits, ‘みかん’);
$fruits[] = ‘みかん’;

これはどちらかに統一すべきです。

シンプルに

KISSの原則「Keep it simple stupid.」(シンプルで愚鈍にする)と言ったりもするようです。おしゃれですね。
シンプルにすることで、読む時に意味がすっと入ってくるようになります。

現状に満足しない

もしかしたらこれが一番大切かもしれません。
個人的に、新しいインプットがないと、現状より良いものは生み出せないと思っています。

新しいより良い考え方や、書き方、プログラミング言語自体の仕様など、常に技術は進歩しています。
誰かがキャッチアップして現場に落とし込んでくれる環境だと良いのですが、そうでない場合はどんどん取り残されていく可能性もあるんです。
なので、新しいことにドンドンチャレンジしてく気持ちが大切かなと思います。
エンジニア一人一人に求められる領域は広くなってきていますし、色んなことができると市場価値も高まります。
何より新しいことを身につけるのって楽しいですよね。

まとめ

基本的なことだけど、意識するとコードがぐっとよくなると思います。
プログラムは書くより読む方が多いとよく言いますが、本当だと思ってます。
読む時のことを考えて書くと自然とキレイに書くことに繋がり、キレイなコードだと保守や変更もしやすくなります。
汚いコードに囲まれる生活を続けると病みます(割とマジで)

散々オススメされている書籍を私からもオススメして締めようと思います。

プリンシプル オブ プログラミング
リーダブルコード

よいプログラミングライフを!