品質の高いソースコードにするために

プログラミング

競馬予想プログラミングに関する記事を「投稿まとめ」で一覧にしてます。この記事は「自動投票」の一覧に含まれてます。一覧の順に読むとステップごとで分かりやすいです。

誰が見ても分かりやすいソースコードを書く

自分しか使うことがないソースコードでも、常に人に見せることを意識しながら書いてください。テキトーに書いてしまうと、時間が経ったら自分が書いたのに何をやってるか分からないソースコード、となることが自分の経験上よくあるからです(苦笑)

  • 関数や変数の命名規則
  • 大文字と小文字の違い
  • インデントの幅

など、プログラムの実行結果に影響がない、どんな小さいことであっても何らかの基準を定めて書くべきです。また、そうすることで次のようなメリットがあります。

  • 時間が経っても読みやすい。
  • 複雑なロジックも理解しやすい。
  • 過去に作った同じパターンをgrepしやすい。
  • 迷いなくサクサク書けて作業がはかどる。

何を基準にするべきか

では、具体的に何を基準にすれば良いのかと言うと、上手い人が書いたソースコードです。

私はいつも言語や製品の提供元が公開するドキュメントやGUIツールが出力するソースコードを基準にしています。インターネットで世界中の人々に発信しながら書きまくるスーパープログラマー達が決めた基準なので、それが他の人にも馴染みあるソースコードになるでしょう。

ということで、この記事で紹介するのは、PostgreSQLのドキュメントを基準としたコーティングルールです。

PostgreSQLのコーティングルール

大文字と小文字の違い

SQLは大文字と小文字を区別しませんがPostgreSQLの場合、ソースコードの読みやすさを目的として次のように使い分けてます。

  • 予約語は大文字。
  • その他は小文字。

これを守るだけでも読みやすくなります。予約語とは、

  • SELECT
  • FROM
  • CREATE

など、システムが予約済みの単語です。当然ですが予約語は変数名に出来ません。maxやsumなどの関数名も小文字で書きます。

WHERE句の抽出条件で指定する値など、いわゆる「リテラル」というヤツは、大文字と小文字を区別します。

変数のネーミングルール

使える文字など必須のルールの中で、変数は名前を自由に付けれます。

「必須のルール」はここでは説明しません。必ず覚える必要もないので、必要になったときググってください。

変数名はひと目みて何の役割を果たしている変数か?分かりやすいほうが良いに決まってます。で、具体的にどうするのかと言うとPostgreSQLの場合、変数名にプレフィックスを使います。

  • パラメータのプレフィックスは p_
  • 変数のプレフィックスは v_

例えば、

  • 競馬場コードを渡すパラメータは p_keibajo_code
  • カーソルを表す変数は v_cursor

といった感じです。ちなみにテーブルの項目名をそのまま変数名にする、というのはどんな言語でも定石です。

当サイト内のサンプルプログラムはすべてPostgreSQLのコーティングルールに従って書いてます。

ソースコードはできるだけ短く

ステップ数を減らす

「ステップ数」とはソースコードの行数のことです。想像してみてください、

  • 10行しかないソースコード
  • 1000行あるソースコード

とでは、どちらのほうがバグが出る可能性が高いと思います?

当たり前ですが行数が多いほうですよね。これはSQLにもプロシージャにも言えることですが、どうすればステップ数を減らせるか?これって本当に必要な処理か?考えながら作ってください。ただし、盲目的に短くするのも考えものです。数行の差で可読性が上がるならステップ数が増えてもOKです。

独立したプロシージャにする

値の違いだけでロジックは同じという場合は、その値を変数にして独立したプロシージャにするのも品質の向上に有効です。なぜかと言えば切り離すことで、

  • 再利用できる可能性がある。
  • テストしやすい。

というメリットがあるからです。ソースコードが短いほどバグの原因も特定しやすいので。切り分けが必ずしも有効というワケではありませんが、その辺のバランスは経験や上手い人のソースコードを参考に判断してください。

「投稿まとめ」にもどる

タイトルとURLをコピーしました