ここまでが筆者の経験に基づくものだ。以降ではConnor教授から聞いた話を紹介する。
#8:マジックナンバーをコード内に書き散らかす
多くのプログラマーは、コードがいったん完成すれば、それは永遠に完璧なものであり続けると考えている。しかし、企業や業界で使用されるソフトウェアの長期的なライフサイクルを最適化するには、状況の変化に耐えられるようなコードを記述しなければならない。
その古典的な例は、マジックナンバーの使用だ。ここでマジック、すなわち魔法という言葉が使われているのは、プログラマーがこういった数字をいつまでも変わらないものと思い込んでいるためだ。
例えば、商品の販売額(sale)に基づく販売手数料(commission)を計算する場合を考えてほしい。現時点の手数料率は3%、すなわち0.03だとしよう。
この場合、commission = .03 * saleというコードを記述するかもしれない。ここでのマジックナンバーは0.03だ。プログラマーはこの値が永久に変わらないという魔法のかかった数字だと考え、コード内に直接0.03という値を書き込んでしまうのだ。
手数料率が変化しなければ、それでも何の問題もない。しかし、何年か後に手数料率が0.5%増え、0.035になった場合、何千行ものコードのなかから修正箇所を見つけるという大変な作業が発生することになる。
マジックナンバーをコード内の各所に直接書き散らかすのではなく、変数や定数として1箇所にまとめて定義しておき、実際に使う場所ではその変数や定数を参照するようにするのだ。commission_rateという変数をあらかじめ定義しておけば、commission = commission_rate * saleという記述が可能となり、該当部分は修正する必要がなくなるわけだ。
また、コード中でマジックナンバーを見かけたのであれば、ユーザーが決定すべき値かどうかを考えてほしい。こういった値は、ひょっとしたら設定画面等でユーザーに設定してもらうべきものなのかもしれない。
#9:日付や時間の処理がいいかげん
ここで、ちょっと難しい質問をしてみたい。1年は何日だろうか?365日というのが普通の答えかもしれないが、2016年の場合にはもちろん366日だ。では365.25日という年はあるだろうか。ない。そんな年はありはしない。
しかし、4年に1度うるう年が訪れるのだから、1年を平均すると365.25日になるという学生もいた。ただ、この平均値を用いた暦日計算プログラムは正しい結果を出せなかった。
計算しようとしている日付が西暦ではない可能性もあるため、暦日計算にはシステムライブラリを利用する方がよいという場合がしばしばある。
時間についても同様だ。潮汐力などの影響により地球の自転速度が変動するのだ。このため、その影響を相殺するために数年毎に1秒が追加される(今までに実施例はないが、1秒を削除するケースも想定されている)。その日はたいていの場合、6月30日か12月31日となっている。これはうるう秒と呼ばれ、その際の時刻は11時59分59秒から11時59分60秒、12時00分00秒へと推移する(削除するケースでは11時59分58秒から12時0分0秒へと推移する)。
他にも問題がある。サマータイムを導入している地域では、トランザクションの順番が崩れてしまう可能性がある。例えば、サマータイム中にトランザクションAが発行され、その直後にサマータイムが終了したと考えてほしい。サマータイムの終了とともに時計の針は1時間戻されるため、時間の取り扱いがずさんであると、そこから1時間以内に発生したトランザクションBはトランザクションAよりも先に発行されたことになってしまう。時間に関するこの手の過ちによって、誤って違約金を請求するなど、さまざまな混乱が生じかねない。
時間の処理に関しても、こういった問題について考慮された優れた言語ライブラリやシステムライブラリが存在している。このため、時間計算処理を自らでコーディングするよりも、既存のライブラリを利用した方がよい場合もしばしばある。