俺的コーディングルール SQL編 - suVeneのアレ

俺的コーディングルール SQL編

 プロジェクトのコーディングルールがこうでなければいけないとか、他人に強制するわけではないが、自分自身で一貫性の無いコードを書くのは気持ち悪いので、オレオレルールを決めてたりする。大抵は デ・ファクト的なルールに沿う形で書くことが多いのだが、SQL や PL/SQL に関してはなかなかデファクトと呼べるものがないので(あるのか?)、メモ的に書きとめておく。

原則
  1. キーワード小文字
  2. オブジェクト名大文字
  3. カンマは後ろ
  4. インデントは半角スペースで 2
  5. 一つの SQL 文でキーワード毎にインデントしない(副問合せ除く)

 まず、1.2. に付いてなのだが、昔は「キーワード=大文字」という意味不明な先入観で大文字で書いていた。ただ、それだと PL/SQL のキーワードも大文字、オブジェクト名も大文字で結局ほとんど大文字になってしまうのと、Shift 押すのが面倒という理由で小文字に変えた。では何故オブジェクト名は大文字のままかというと、これは利用しているツールの問題と、つづり間違いを極力減らす為にオブジェクト名はなるべく Copy & Paste するからであり、それほど負担にはならないという理由からだ。キーワード小文字との対比という意味でもよい。
 3. は、SQL は経験上、前カンマが慣習的に多い気がするのだが、どうも他のプログラムと並列していると後ろカンマに慣れてしまい、どうも前カンマが気持ち悪い。ただ、やはり前カンマにしようかな~などと悩ましいところである。(理由は後述)
 4. インデントがタブかスペースかについては、色んなところで議論されているのだが、俺はスペースを使う。色んな理由から。昔は 4 インデントをしていたのだが、HTML や XML などの入れ子構造や、ちょっと条件文を重ねたときに深くなりすぎるので、最近では 2インデントをよく利用してる。タブストップが無い環境やタブ文字が入ってしまう環境で編集するときにも楽だし(あんまりないけど)。
 
というわけで基本的なオレ的書き方。

select
f1.ID,
f1.ITEM1,
f1.ITEM2,
f2.ITEM3,
m1.USER_ID,
m1.USER_NAME
from
table_head f1,
table_detail f2,
user_master m1
where not exists (
select 1 from tableXXX s1
where s1.ID = f1.ID
)
and f1.ID = f2.ID
and f2.USER_ID = m1.USER_ID
and f2.ITEM3 = 'xxx'
order by m1.user_id, f1.id, f1.item, f2.item

気をつけているポイントとしては

  1. select, from の次は改行をつける(項目が単一の場合は除く)
  2. where は1個目の条件を書いてから改行
  3. 各キーワードはインデントせずに揃える
  4. from句のテーブル名のエイリアスは略語にしない
  5. 結合条件を先に書く

大抵の理由はインデントのしやすさというか、なるべく深くならないように気をつけるという点からきている。どういうことかというと

select f1.ID,
f1.ITEM1,
f1.ITEM2,
f2.ITEM3,
m1.USER_ID,
m1.USER_NAME
from table_head f1,
table_detail f2,
user_master m1
where not exists (
select 1 from tableXXX s1
where s1.ID = f1.ID
)
and f1.ID = f2.ID
and f2.USER_ID = m1.USER_ID
and f2.ITEM3 = 'xxx'
order by m1.user_id, f1.id, f1.item, f2.item

と書いてしまうと、2個目以降のオブジェクト名や、条件文に副問合せが発生した場合などにかなり深くなる。タブストップで揃わない位置に並べるのも面倒だ。
 オブジェクト(主にテーブル)のエイリアスは大抵つける、その際、テーブル名を略したエイリアスをつけない(TOKUISAKI_MST TOK, USER_MST USR みたいな)。理由は、略文字はテーブル名が増えたり、似たような名前のテーブルが並ぶと、ぱっと見で判断しにくいから。その点数字だとすぐ見分けが付く。(from 句を参照しないとだめだが) 頭文字の f というのは特に意味なし。

 たまに and を後ろにつける人を見かけるけども、あんまり好きじゃない。でも、 or は後ろにつけるのが好き。

 結合条件は from 句で innerjoin, leftjoin しても良いのだが、ORACLE を触ることが多かったので where 句に書くことにしている(今は ORACLE でもその書き方ができるので、そちらのほうが良いのかもしれないけど)。ただ、結合条件と抽出条件を考えたとき、変更が多いのは後者だし、リレーションは決まっているので 結合を先に書くというルールだけ。ただし、exists だけは先に書く。これは RBO の時の名残で。

 先ほども書いたが、最近悩んでいるのが、カンマの位置。大抵の言語では後ろカンマが標準的だと思うんだが、SQL に関しては 前カンマのほうが効率が良いのではないかと思っている。理由は開発中は取得フィールドの追加変更や切り貼りが多いから。というのも、前カンマだと 追加が簡単。後ろカンマだと、前のフィールドのカンマをつけなければならない。仕様的には、先頭のフィールドよりも追加のほうが多いし、先頭は Primary Key などが並んでいることが多いので、大抵決まっている。他の SQL 書くときにも Copy&Paste が簡単だからだ。

select
f1.ID
, f1.ITEM1
, f1.ITEM2
, f2.ITEM3
, m1.USER_ID
, m1.USER_NAME
, m1.NICK_NAME -- 追加
……

とまぁ、他人が読んでもとてもくだらない話だろうとは思うが、よく使う select 句に関してはこんな感じ。
そこのあなたはどんな事に気をつけてコーディングしているのだろうか、大変気になるところだ。

スポンサーリンク
スポンサーリンク

コメント

  1. DENKEN より:

    『俺的コーディングルールSQL編』によせて

    『俺的コーディングルール SQL編』に刺激を受けて 私のSQLの書き方を紹介します。 紹介されている書き方と比較したらわかりやすいと思うので、 まずは上記のサイトで紹介されている書き方を以下に。 select f1.ID, f1.ITEM1, f1.ITEM2, f2.ITEM3, m1.USER_ID, m1.USER_NAME

  2. テンコ より:

    半角スペース詰められるのかw

  3. テンコ より:

    俺は
    SELECT A,
    B
    FROM XXXXX M1
    LEFT JOIN (
    SELECT A,
    B
    FROM YYYYYY
    WHERE A = ‘AA’
    AND AA = ‘AA’
    ) T1
    ON M1.A = T1.A
    WHERE M1.A = ‘AA’
    AND ・・・・

    って書くけど、あまりポリシー無し
    前カンマは確かに修正しやすいけど
    見てて気持ち悪くてなんかやだ

  4. suVene より:

    何その左詰w
    A フィールドと B フィールドの位置キモチワワル!

  5. 俺的コーディングルール SQL編 – suVeneのアレ http://t.co/ZVeMV2r

コメントをどうぞ

メールアドレスが公開されることはありません。