【ゆかむアドベントカレンダー】4日目 あえて妥協したコードを書く時

今日はプログラミングについて書きたいと思います。

コードには「関数は短い方が良い」とか「変数の使い回しは良くない」とか、様々なセオリーがあります。
でもそれらを全て守っていれる訳ではなく、様々なトレードオフがあって妥協するときもあります。

そうなると、どこまでが許せる妥協でどこからが許せない妥協かという話になってきます。
この議論はコンテキストによるので各論の話になってしまいます。

私はとりあえず「妥協した理由を説明できるか」が分かれ目かなと個人的に思っています。
「なんとなくこうしました」というのはNGで、メリデメを言語化できているかが大事という思いですね。

そしてその様な説明を必要とする状況、つまりコードで妥協をする時は言語やフレームワークの性質との兼ね合いによるものである時が多いです。

例えば私はDelphiでは「変数の使い回し」をあえて許容するときがあります。

Delphiは関数の上部に変数を宣言する箇所があり、関数内にはローカル変数を持っていないです。その中に複数のfor文を書く場合は私はあえて変数を使いまわすときがあります。
(一つの関数の中にfor文が何個もある時点でイケてないという話もありますが、ここではその議論はしません。また私はDelphiのエキスパートではなくまた最近のDelphiには触れていないため、言語仕様については各種ドキュメントを必ずご参照下さい)

procedure hoge;
var
  i:Integer;
begin
  for i:=0 to 10 do 
  begin
    //なんらかの処理
  end;

  for i:=0 to 10 do 
  begin
    //なんらかの処理
  end;
end;

上のコードを下のようにリファクタリングするメリットは薄いと思っています。

procedure hoge;
var
  i,j:Integer;
begin
  for i:=0 to 10 do 
  begin
    //なんらかの処理
  end;

  for j:=0 to 10 do 
  begin
    //なんらかの処理
  end;
end;

for文の中でiという変数をカウンターとして使う文化は広く浸透していて、i・j・kなどfor文の数だけ変数を用意するのはかえってわかりづらいと考えるからです。

以上の私の対応には賛同しない方もいらっしゃると思います（実際同僚からも反対意見がありました）。
議論はさて置いてここで私が注目するのは、「セオリーを妥協するか否かのトレードオフは技術仕様（言語仕様やフレームワークなど）の要素との兼ね合いで発生する事が多い」という事です。

for文が独自の変数スコープを持つ事ができる言語であればこの様な議論は発生しないです。

明日はゆかむが担当します