あまりにも見ていてポエってきたのでポエります。
バズり狙いのためだけに無責任なタイトルを書かれるのは悲しい事です。
9/17 追記
私の記事を含めた内容で記事を頂きました。
参考になり考えさせられましたので文末に追記します。
本編感想
const decimal ランク1上限 = 1_625_000;
const decimal ランク1控除額 = 650_000;
const decimal ランク2上限 = 1_800_000;
const decimal ランク2控除率 = 0.40m;
これをわかりやすいという人はいないと思います。
わかりにくいだけならまだしも、タイプミスを防げません。
ランク3上限 のところを ランク2上限 とタイプミスしても気が付かないでしょう。
定数内の数字とマジックナンバーの数字を打ち間違える確率はマジックナンバーの方が高いでしょう。
私はうっかりやなので入力ミスしないよう出来る限り変数なり定数なりに入れます。
記事内の変数名が全て日本語なのでVBAだと思いますが、インテリセンスが使用しにくいと思うので私なら下記にします。
MaximumRankOne
MaximumRankTwo
DeductionRankOne
DeductionRankTwo
英語赤点なのでWeblio直訳名です。
インテリセンスを使用すれば
mro
mrt
dro
drt の3入力で概ね打ち込めます。
名前の順番や意味合い、理解度が気になる場合はRank_One_MaximumでもランクThree上限でも大丈夫だと思います。
ランク一上限とかランク壱上限でもいいような気がしてきました。
現実には定数の値の修正では足りない変更が入る確率のほうが高いでしょう。
ほとんどの処理には名前があります。
「消費税額」や「所得控除額」という仕様にある名前をそのまま関数にして、仕様と同じになるように実装を書きます。
それをすれば、定数化はほとんど必要ないでしょう。
修正が足りないだけで増える要因にはなっていません。
マジックナンバー「1_625_000」を入力するよりもインテリセンスを活用した方が入力速度が速く確実に記述出来ます。
Comment感想
私はマジックナンバーを使うほうがいいと思っています。
というのも、数には業務にディペンドしてその業務では自明なものと思っています。
つまり、業務の理解ができていれば数は頭に入っている。
マジックナンバーをみてピンとこない人はプログラムをメンテすべきではない。
むしろ、それがわかるまで業務理解を進めたほうがいい、と思ってます。
私が感じた印象を例えます。
Excelのマクロで数時間の作業を一瞬で終わらせた時に上司に言われる一言。
「プログラムには温かみがないし確実ではないから電卓を使ってちゃんと計算しなさい」
クライアントが何か設定を変更したい時、option項目を変更するだけで問題ないようにプログラムを組みます。
ささいな変更まで中身の理解は必須ですか？
必要だったとして消費税として使われている0.1という数字を確認のためだけにプログラム内から全て探す労力と時間を想像するとげんなりします。
static final int ONE = 1;
こういう何の意味もない定数化はNG。
私も経験があります。
ONE * ONE
int[ONE]
ONE.ToString() + "回目"
まだまだ羅列する事が出来ますが狂気の沙汰です。
いちからか？ いちからせつめいしないとだめか？
消費税を計算するというコンテキストで、0.08とか0.1という数値を見れば、それが消費税率であるとほぼ全員がわかるでしょう。
概ね分かると思いますがひとつ問題があります。
2014年から消費税率は一律8％です。
2019年から消費税は10%かつ軽減税率8%です
0.08という数字は未修正の消費税なのか、修正済みの軽減税率の8%なのかかこの数字だけでは確定できません。
顧客が軽減税率適用商品しか扱っていないからと前任者が勝手に判断して修正したにも関わらずこの数値かもしれません。
後から意味合いが増えた形ですが意地悪な発想でしょうか。
私としては名前が付けられるのなら全て名前を付けてほしいです。
関数処理でも定数処理でもかまいません。
本来不要な推測を求められてミスした時はこちらの責任になる事が多々あります。
プログラムの挙動どころか制作者の腕すら推測しながら作業するのは苦しいんです。
定数化かどうかは置いといて、その数値が何なのかを説明するために定数でも変数でも良いので
入れておいて名付けをして欲しいというのが「マジックナンバー使うな」という事の本当の意味じゃないかな。
本当に同意しますし私もこの気持ちです。
マジックナンバーや数字リテラルをどんどん使って困るのは現在のあなたではありません。
そのプログラムの改修を命じられた後任者だったり、遠い過去に作られた手抜きプログラムの改修を命じられたあなたです。
その過去にプログラムを作ったのもあなたかもしれません。
マジックナンバー（数字リテラル？）を使っていい場合
上記の記事では公式に当てはまる数字は直接入力してよいとされています。
これに関しては同意します。
錐の体積や角度の変換に使用する不変の数字をあえて命名して使用しなければならない理由がありません。
三角形の面積を求める際、底辺×高さ÷2で÷2をリテラルで使用してはならないと言われれば違和感があります。
呼び出し関数名等で三角形の計算などと命名すべき場面であり、÷2に全ての責任を任せるべきではありません。
（三角形の底辺等の助長な名前も排除されるべきです）
私の参照元記事commentにもありますが
いや、でも変更されることのない数学の定理と変更の可能性のあるビジネスロジックを比較するのも違うか…難しいですね。
という点を考慮出来るかが重要だと考えます。
此処から先は蛇足です。
色空間の変換に関して簡単な調査をしましたが、RGBへの変換方式だけでも多数の変換方式がありました。
その中にAdobe RGBがあるため、私の記事は怪しくなります。
数学の公式であればロジックが変更される可能性は限りなく低いと主張出来ます。
しかしながらAdobeRGBは一企業が制定したロジックを使用しています。
変換方式を容易に変更する訳がないと言いたくなりますが、文字コードでハングルの大移動という前例がある以上は唐突に変換式が変更になる可能性もあります。
それを消費税の計算とどこまで違うのかという話となるとすぐに答えを出せません。
勿論、ランク1上限や消費税に関してリテラルで打ち込む事は今後もありません。
私には上記のような少数の例外とその理由について自身で納得出来る程度の理由をもう一度考える時間が必要です。