コードをシンプルに保つために考える4つのこと

プログラミングをする上で注意すべきことがあります。
それは後でも読めるコードを書くことです。
後でも読めるという事は保守がしやすいということです。
保守というのは機能の追加、修正です。

プログラミングで最終的に求められるのは「設計」です。
ウォーターフォール型のシステム開発では、設計、プログラミングとフェーズは分かれています。
しかし、プログラミングにも設計が含まれます。
クラスやロジックをどのように実装するかという設計です。

仕様書通りに実装するだけ、フローチャートをそのままコードにするだけではプログラミングが本当に出来てるとは言えません。
なぜなら後の事、保守を考えていないからです。
作ったら終わりではなくリリースしてからの方が大切なのです。

リリースしてからの変更というのは、動いた状態で機能の追加、修正ができなければなりません。
新規で作るより動いているものに手を加える方がリスクが高くそれなりのスキルが必要です。
しかも、コードが複雑になると、いくら優秀なプログラマーでも読むのが困難になって手がおえません。
私の会社でもやっかいなシステムが１つありますし、修正がしにくいシステムがいくつも出てきています。

プログラムをリリースしてから困らないために、実装の段階で注意した方がいいコードをシンプルに保つための基本的な4点を上げていきます。

1.変数、メソッドの名前を考える

変数に「flg1」「flg2」などの名前をつけていませんか？
メソッドに値を取得するのに「setHoge()」という名前をつけてませんか？
後で読むと何の事がわかりません。
「変数やメソッドの宣言箇所にコメントを書けばいいじゃない」と言う声が聞こえてきそうですが、それだと宣言部分でしかわかりません。
使用箇所でその都度書くのは冗長でコードが読みにくくなります。
変数、メソッドにきっちりした名前を付けた方が読みやすいので、少し考えて考えてみましょう。
名前のつけ方

ローマ字より英語でつける

長過ぎず短すぎず意味が明確になるようにする

変数は名詞、メソッドは動詞にする

私は日本語をGoogle翻訳で英語に翻訳しています。

2.if文を使わない方法を考える

ほとんどの人は何かしらの条件で分岐が必要であればif文を使うと思います。
便利なif文ですが使いすぎると条件が多くなったり、ネストしてコードを読むのが大変になってきます。
そのロジックにif文が必要なのか、if文を使わない方法を考えましょう。
if文を減らす方法

オブジェクト指向のポリモーフィズム(多態性)を使う

１つの変数に状態を持たせて分岐させるのではなく、メソッドごとに状態を作って直接呼び出すようにする

3.フラグを使わない方法を考える

初心者にありがちなのが、なにかとフラグを使うことです。
1つのフラグに「1のときA、2のときB、３のときC…」と意味付けをしていきます。
フラグの量が多くなると条件分岐が多くなりコードの複雑さを招きます。
そのフラグが本当に必要なものか、フラグを使わない方法を考えましょう。
フラグを減らす方法

true(1)かfalse(0)しかとらないboolean型にする

フラグで解決しようとしない

減らす方法が抽象的ですが、フラグはなるべく使わないようにすれば使わなくなってきます。

4.メソッドの内容を短く分割できないか考える

プログラミングの経験が浅い、自分しか使わないプログラムのとき、1メソッドに長々とコードを書いてしまうことが多いです。
1つのメソッドに機能を持ちすぎて、修正しようにも他の所に影響を与えてしまいます。
リリース後の修正で一番困るパターンです。
そうならないように中身が長くなってしまったメソッドを別メソッドとして書き出します。
「何行ぐらいがいいの？」と聞かれますが、行数より機能で考えてください。
メソッドを分割する基準