競馬予想プログラミングに関する記事を「投稿まとめ」で一覧にしてます。この記事は「自動投票」の一覧に含まれてます。一覧の順に読むとステップごとで分かりやすいです。
誰が見ても分かりやすいソースコードを書く
自分しか使うことがないソースコードでも、常に人に見せることを意識しながら書いてください。テキトーに書いてしまうと、時間が経ったら自分が書いたのに何をやってるか分からないソースコード、となることが自分の経験上よくあるからです（苦笑）
- 関数や変数の命名規則
- 大文字と小文字の違い
- インデントの幅
など、プログラムの実行結果に影響がない、どんな小さいことであっても何らかの基準を定めて書くべきです。また、そうすることで次のようなメリットがあります。
- 時間が経っても読みやすい。
- 複雑なロジックも理解しやすい。
- 過去に作った同じパターンをgrepしやすい。
- 迷いなくサクサク書けて作業がはかどる。
何を基準にするべきか
では、具体的に何を基準にすれば良いのかと言うと、上手い人が書いたソースコードです。
私はいつも言語や製品の提供元が公開するドキュメントやGUIツールが出力するソースコードを基準にしています。インターネットで世界中の人々に発信しながら書きまくるスーパープログラマー達が決めた基準なので、それが他の人にも馴染みあるソースコードになるでしょう。
ということで、この記事で紹介するのは、PostgreSQLのドキュメントを基準としたコーティングルールです。
PostgreSQLのコーティングルール
大文字と小文字の違い
SQLは大文字と小文字を区別しませんがPostgreSQLの場合、ソースコードの読みやすさを目的として次のように使い分けてます。
- 予約語は大文字。
- その他は小文字。
これを守るだけでも読みやすくなります。予約語とは、
- SELECT
- FROM
- CREATE
など、システムが予約済みの単語です。当然ですが予約語は変数名に出来ません。maxやsumなどの関数名も小文字で書きます。
WHERE句の抽出条件で指定する値など、いわゆる「リテラル」というヤツは、大文字と小文字を区別します。
■リテラルとは、直接表現の値
AND ra.kaisai_nen = ‘2023‘
AND ra.kaisai_tsukihi = ‘0917‘
AND ra.keibajo_code = ‘09‘
変数のネーミングルール
使える文字など必須のルールの中で、変数は名前を自由に付けれます。
「必須のルール」はここでは説明しません。必ず覚える必要もないので、必要になったときググってください。
変数名はひと目みて何の役割を果たしている変数か？分かりやすいほうが良いに決まってます。で、具体的にどうするのかと言うとPostgreSQLの場合、変数名にプレフィックスを使います。
- パラメータのプレフィックスは p_
- 変数のプレフィックスは v_
例えば、
- 競馬場コードを渡すパラメータは p_keibajo_code
- カーソルを表す変数は v_cursor
といった感じです。ちなみにテーブルの項目名をそのまま変数名にする、というのはどんな言語でも定石です。
当サイト内のサンプルプログラムはすべてPostgreSQLのコーティングルールに従って書いてます。
ソースコードはできるだけ短く
ステップ数を減らす
「ステップ数」とはソースコードの行数のことです。想像してみてください、
- 10行しかないソースコード
- 1000行あるソースコード
とでは、どちらのほうがバグが出る可能性が高いと思います？当たり前ですが行数が多いほうですよね。
「バグ」とは、英単語で「虫」という意味を持ち、コンピュータの分野ではプログラム内に存在する誤りを指します。
これはSQLにもプロシージャにも言えることですが、
- どうすればステップ数を減らせるか？
- これって本当に必要な処理か？
考えながら作ってください。
ただし、盲目的に短くするのも考えものです。数行の差で可読性が上がるならステップ数が増えてもOKです。
独立したプロシージャにする
値の違いだけでロジックは同じという場合は、その値を変数にして独立したプロシージャにするのも品質の向上に有効です。なぜかと言えば切り離すことで、
- 再利用できる可能性がある。
- テストしやすい。
というメリットがあるからです。ソースコードが短いほどバグの原因も特定しやすいので。切り分けが必ずしも有効というワケではありませんが、その辺のバランスは経験や上手い人のソースコードを参考に判断してください。
