SVNと書いてサヴンと読む

ゴールデンカムイのアニメ一気見してる（途中）。ごきげんよう。

SQLのSELECT句のカンマを行頭に書きたがる連中がいますが。
（連中呼ばわりしてる時点で快く思ってないのバレバレだ）
いえ書き方自体はどちらでもというかコーディングルールならば
従うだけですが、そのように書く目的については異論ありまして。

差分を比較したときわかりやすいように、という言い分ですが、
べつに行末にカンマつけて項目追加しても差異が1行か2行かの
違いでしかなく、1行だけのほうが比較しやすいとは感じません。
それよりもその根底にある思想、SQLに限らずプログラム全般に
関してですが、修正するとき差分を最小限にしたいという思惑が
あるのではないでしょうか。
そのような考え方は保守において問題を引き起こす元凶です。

SELECT文に項目を増やす場合、1行だけの変更では済まないことが
実際には多いと思います。
新たにテーブルを結合したり、検索条件や結合条件を追加したり。
そのときに修正コード量を少なくすることにこだわってしまうと、
SQL全体としてパフォーマンスが落ちたり、さらには条件をつける
場所を間違えて結果が正しくなくなるなどエンバグを招きます。

修正時に新たなバグを仕込んでしまうのはプログラムあるあるとは
言え、考え方一つでバグを生み出しにくくする保守は可能です。
それが上述した差分の記述量にこだわることなかれというものです。



プログラミング言語だったら1命令ごとに処理が行われますから
行単位で差分を比較することに意味はありますが、SQLの場合は
文全体で一つの処理です。
それを行単位で見比べようとすると、修正内容が把握しづらく
なったり問題点に気づきにくくなるおそれがあります。
さらにはSQLだけでなく呼び出し元のプログラムも含めて修正が
必要な場合もありますが、そのような一段上がった視点からの
発想にも至れなくなります。

さらに指摘するならば、修正を最小限にしたいという考え方は
保守担当者の責任逃れに聞こえます。
自分は最初の開発者じゃないからなるべく触りたくない、などと
委縮していると、かえって変な場所にコードを書いて問題の元に
なったり、バージョンアップのたびにどんどん処理が重くなると
いったことが起こります。
むしろ保守こそシステム全体を理解して、必要とあれば設計や
プログラム構成から大胆に見直すなど最適な修正を行う能力が
求められると思います。

おそらく、バージョン管理システムが普及して修正前との差異が
容易に可視化されるようになったから生まれた発想なのでしょう。
ですが、差分が1行だけしか出てこないから見栄えがよいなどと
いうのはまったく本質的ではなく、反対に大幅な変更を加えても
修正前の状態が残っている、元に戻せることこそ機能の本筋です。
コードの見た目よりも実際にプログラムを動かしたときの正しさや
性能を優先して善し悪しが議論されるべきではないでしょうか。