これはシンボリックな定数の過剰使用ですか？

私はソフトウェアエンジニアリングが初めてなので、学習演習としてチェスゲームを書きました。私の友人はそれを見て、私のコードが次のように見えることを指摘しました

for (int i = 0; i < 8; i++){
    for (int j = 0; j < 8; j++){

彼は代わりにあるべきだと主張した

for (int i = 0; i < CHESS_CONST; i++){
    for (int j = 0; j < CHESS_CONST; j++){

私が今考えるのが面倒ではないいくつかのより良いシンボル名で。

もちろん、私は一般的にマジックナンバーの使用を避けることを知っていますが、

1. この数は変更されません。
2. 番号はコード全体で非常に多くの場所で使用されているため、名前はとにかく説明的ではありません。そして
3. チェスプログラムのソースコードを調べている人は、8の目的を知るためにチェスについて十分に知っている必要があります。

シンボリック定数は本当に必要ありません。

では、皆さんはどう思いますか？これはやり過ぎですか、それとも慣習に沿ってシンボルを使用する必要がありますか？

あなたの友人は、シンボリック名を使用するのが正しいですが、名前は間違いなくよりわかりやすい名前である必要があると思います（のBOARD_WIDTH代わりにCHESS_CONST）。

プログラムの存続期間中に数値が変更されない場合でも、プログラム内に番号8が別の意味で発生する他の場所がある場合があります。「8」をBOARD_WIDTHボード幅の意味で置き換え、別の記号名を使用すると、これらの異なる意味が明示的、明白になり、プログラム全体が読みやすく、保守しやすくなります。ボード幅に依存するコード内のすべての場所をすばやく特定する必要がある場合は、プログラム全体のグローバル検索（または環境で提供されている場合は逆シンボル検索）も実行できます。

番号の名前を選択する方法（または選択しない方法）については、この以前のSE.SEの投稿も参照してください。

サイドノートとして、コメントでここで説明されているため、実際のプログラムのコードで、変数がボードのi行と列を参照するjか、またはその逆の場合、変数名を選択することをお勧めしますrowおよびのように区別を明確にしcolます。そのような名前の利点は、間違ったコードを間違って見えるようにすることです。

OK、私が持っているいくつかのコメントがあります：

マジックナンバーを取り除くことは素晴らしいアイデアです。DRYと呼ばれる概念がありますが、これはしばしば誤って伝えられますが、アイデアはプロジェクトの概念の知識を複製しないことです。したがって、ChessBoardというクラスがある場合は、BOARD_SIZEまたはChessBoard.SIZEという定数をそれに添付しておくことができます。このように、この情報の唯一のソースがあります。また、これは後で読みやすくなります：

for (int i = 0; i < ChessBoard.SIZE; i++){
  for (int j = 0; j < ChessBoard.SIZE; j++){

数が変わらない場合でも、プログラムは間違いなく優れています。それを読んでいる人は誰でも、コードが何をしているかについての詳細を知っています。

悪い名前は名前がないよりも悪いですが、それは何かに名前を付けるべきではないという意味ではありません。名前を変更するだけです。お風呂の水で赤ちゃんを捨てないでください。：p名前は、それが何を説明しているかをよく理解している限り、説明的なものにすることができます。次に、その概念を複数の異なるものに使用できます。

本当に必要なのは、名前が付けられているか裸であるかにかかわらず、定数への広告の吐き気の参照を排除することです：

for_each_chess_square (row, col) {
  /*...*/
}

このようなループなどを繰り返して定数を実際に増やす場合は、に固執することをお勧めします8。

8自己記述的です。他の何かを表すマクロではありません。

You Ai n't Never Gonna（TM）は9x9のチェスプログラムに変えます。もしあなたがそうするなら、8の急増は大きな困難ではありません。

150,000行のコードベースでトークン8を検索し、どの発生が何を意味するかを数秒で分類できます。

もっと重要なのは、チェスの知識ができるだけ少ない場所に集中するようにコードをモジュール化することです。文字通り8が現れるチェス固有のモジュールを1つ、2つ、または3つ持つ方が、シンボリック名で8を参照するチェス固有の責任を伴う37個のモジュールよりも優れています。

この8定数がプログラムの緊張の原因になる場合、またはその場合、その時点で簡単に修正できます。現在発生している実際の問題を修正します。あなたがその特定の8によって妨げられていると感じないなら、その本能で行ってください。

将来、代替のボード寸法をサポートしたいとします。その場合、これらのループは、名前付き定数を使用するか8、またはを使用するかを変更する必要があります。ディメンションはboard.widthandなどの式によって取得されるためboard.heightです。のBOARD_SIZE代わりに持っている場合8、これらの場所は見つけやすくなります。それで、それはより少ない努力です。ただし、交換の手間を忘れてはならない8とのBOARD_SIZE最初の場所で。全体的な労力は少なくありません。コードを1回パスしてに変更8しBOARD_SIZE、別のコードを使用し8て代替ディメンションをサポートすることは、単に代替ディメンションサポートに移行するよりも安くはありません。

これは、純粋に冷静な客観的なリスク/利益分析からも見ることができます。現在、プログラムにはベア定数があります。これらが定数に置き換えられた場合、利点はありません。プログラムは同一です。どんな変更でも、ゼロ以外のリスクがあります。この場合、それは小さいです。それでも、利益なしでリスクをとるべきではありません。この推論に直面して変化を「販売」するためには、利益を仮定する必要があります。これは、別のプログラムに役立つ将来の利益、つまり現在存在しないプログラムの将来のバージョンです。そのようなプログラムが計画されている場合、この仮説とそれに関連する推論は真正であり、真剣に受け止められるべきです。

たとえば、これらの定数をさらに増殖させるコードを追加するのに何日も離れている場合は、それらを廃止することができます。定数のそれらのインスタンスがこれまでに存在するほぼすべてのインスタンスである場合、なぜ気にしますか。

商用ソフトウェアで作業する場合、ROIの引数も適用されます。プログラムが販売されておらず、ハードコードされた数値を定数に変更しても販売が改善されない場合、その労力は補償されません。この変更は、時間の投資に対するリターンをゼロにします。ROIの議論はお金を超えて一般化します。あなたは時間と労力を費やしてプログラムを作成し、それから何かを得ました。それがあなたの「R」です。単独でその変更を行うことにより、それが何であれ、その「R」の多くを取得する場合、すべての手段によって。さらなる開発の計画があり、その変更により「R」が改善される場合も同様です。変更がすぐにまたは予測可能な「R」を持たない場合は、忘れてください。