番外編２

   チームで開発を行う場合、ある程度ルールづけされたコーディングスタイルが求められます。個人個人が思うままにコーディングをした結果、出来上がったものがコーディングした本人しかわからない、といった事はよくあります。それを回避するために、コーディングの指針となるコーディング規約というものがあります。弊社でも請負開発を行う際、コーディング規約に則ったコーディングを行います。
   「ColdFusionのすゝめ」連載最終回の今回は、弊社で使用しているコーディング規約を紹介します。全ては解説しきれないので、ColdFusionに関連するところを中心にいくつか解説します。
コーディング規約の完全版は、当ページの最後にダウンロードできるようになっています。

■コーディング規約について

   まずは、このコーディング規約の位置づけについて定義しています。この規約は「100%この通りに書け」というものではありません。プロジェクトの内容や規模、既存システムや外部パッケージとの連携の有無など、プロジェクトによって、開発条件・環境は様々です。ベースはこの規約を使用し、そのプロジェクトに最適な形を都度検討してカスタマイズして使用することを推奨しています。

■目的

   目的を述べる前に、もしコーディング規約がなかったらどうなるでしょう。例えば、顧客名という変数を記述するケース一つ取っても、ある人は「CustomerName」、またある人は「kokyakuMei」、またある人は「customer_nm」とするかもしれません。命名だけでなく、同じ目的を達成するためのプログラムの書き方は、何通りもあります。規約がなければ各人バラバラのソースになってしまうのは当然です。そこで、ある程度ルールづけされたプログラムになるよう取り決めたのがコーディング規約です。ルールに縛られるのは、プログラムの世界だけではなく嫌なことですが、このルールによって以下事が可能になります。
・ソースの可読性向上
    皆が同じルールに則ってコーディングするので、どのソースも読みやすくなります。
・不具合の発生の抑制
    ソースの可読性が向上すると、自身でコーディングしている時もそうですし、ソースレビューした時
    なども不具合を発見しやすいです。
・保守性の向上
    ルールに基づいたプログラムは、コーディング担当者以外が見ても戸惑うことはありません。
これらが、コーディング規約を採用する目的です。

■命名規則

   ここでは、以下の項目ごとに命名規則を定めています。
命名規則に関しては、ここで定義しているものが最適というわけではなく、各企業や組織ごとに自由に決めていいと思います。
ColdFusionに特化したルールではないため、詳細は割愛いたします。
   ・共通
   ・ファイル名
   ・メソッド名
   ・クエリ名
   ・コンポーネントのインスタンス名
   ・変数名
   ・formフィールド名
   ・配列名
   ・構造体名
   ・ループカウンタ

■コメント

   プログラム中に記述するコメントに関して定義しています。以下の箇所には最低限コメントを記述するよう定義しています。
   ・変数の宣言/初期化
   ・配列/構造体の宣言
   ・条件分岐
   ・ファイルのインクルード
   ・コンポーネントの呼び出し/コンポーネントの引数
   ・その他必要と思われるところ

■ファイルヘッダ

   各プログラムのヘッダ情報として記述する項目を定義しています。そのプログラムの説明であったり、修正履歴等を記述します。
   TITLE           ：画面・機能名
   FUNCTION   ：機能概要
   FILENAE      ：ファイル名
   CODED        ：作成日/作成者
   REVISION    ：修正内容
   NOTE           ：備考

■コード表記

   ここからは、ColdFusion独自のものが中心となります。ColdFusionのコードの書き方について、細かいところを定義しています。
以下にいくつか細かく紹介します。
 
変数の接頭辞は省略しない。
ただし、意図的に同一変数名で異なる形式の変数を使用する場合は除きます。
例）Variables.CustomerName, Arguments.EmployeeName, Session.SecurityCode
これは、前回第９回の記事の「接頭辞を活用しよう」でも書きましたので詳しくはそちらを見てください。
視認性の向上とパフォーマンスの向上に繋がります。

 

<cfset>を多数用いる場合は、<cfscript>を使用する。
例）○<cfscript>
            Valiables.aaa = 1;
            Valiables.bbb = 2;
            Valiables.ccc = 3;
            Valiables.ddd = 4;
            Valiables.eee = 5;
        </cfscript>
 
     ×<cfset Variables.aaa = 1>
        <cfset Variables.bbb = 2>
        <cfset Variables.ccc = 3>
        <cfset Variables.ddd = 4>
        <cfset Variables.eee = 5>
こちらも前回第９回の記事の「CFSCRIPTは早い！」で紹介しましたが、CFタグよりCFSCRIPTの方が早いためです。

 

<cfset>で変数に値を格納するときは、「"」や「#」でくくらない。
例）○<cfset Variables.MyName = aryMyArray[1]>
     ×<cfset Variables.MyName = “#aryMyArray[1]#”>
どちらの書き方でも同じ結果になりますが、「"」や「#」でくくらない方法で統一しています。

 

<cfif>で「true」「false」を判断する場合は、「is true」「EQ false」は使用しない。
例）○<cfif IsNumeric(Variables.TotalCount)>
     ×<cfif IsNumeric(Variables.TotalCount) is true>
こちらも結果は同じですが、この様な形で統一します。

 

<cfoutput>タグは極力OUTPUTする箇所にだけ使用する。
ソースの最初と最後に<cfoutput>タグを記述すれば、都度記述しなくてすむので楽なのですが、不要なところまでColdFusion側での無駄な変換が発生します。

 

<cfswitch>での<defaultcase>は不要でも必ず記述する
例）
<cfswitch expression="#Variables.Code#”>
    <cfcase value="10″>
        処理１
    <cfcase value="20″>
        処理２
    <cfcase value="30″>
        処理３
    <cfcase value="40″>
        処理４
    <cfcase value="50″>
        処理５
    <cfdefaultcase>
        エラー処理
</cfswitch>
絶対にVariables.Codeが10〜50以外はありえない事はわかっている時でも、もしそのケースが発生した時の事も考慮するのが正しい姿です。万が一10〜50以外のケースが発生した時のために、エラー処理を記述しましょう。

 

同一グループのタグの属性の順番はそろえる
属性の順番は問わないが、同一グループ内では順番を揃えて記述する。
例）○<cfargument name="UseID” required="true”  hint="ユーザーID”>
        <cfargument name="Name” required="true”  hint="名前”>
        <cfargument name="Age”    required="false” default="20″>
 
     ×<cfargument name="UseID”   required="true” hint="ユーザーID”>
        <cfargument required="true” name="Name”   hint="名前”>
        <cfargument hint="年齢”         name="Age”      required="false”>
後から属性を追加した時などにやりがちですが、属性の順番がバラバラだと、例えば上の例で見るとdefault属性が漏れていたとしても気づきにくいことがわかります。面倒でも統一するよう心がけましょう。

 

■ダウンロード

ColdFusionコーディング規約は以下からダウンロードして下さい。

■さいごに

   今回紹介したものは、規約のごく一部です。コーディング規約をダウンロードしていただくと全てご覧いただけます。
この規約はまだまだ完全なものではありません。よりいいルールがあれば追加・改定を行っています。コーディング規約なしで開発している方は、是非こちらのコーディング規約をカスタマイズして使用してみてはいかがでしょうか。
その際の注意点は、１点。あまり細かくなりすぎないことです。あまりに膨大なルールを設定してしまうと、開発者が覚えきれず、結果としてルールに沿わないものができてしまいます。また、ルールを意識するあまり、開発効率が落ちては元も子もありません。多すぎず少なすぎず適度な量がいいかと思います。
   今回の記事で「ColdFusionのすゝめ」の連載は最後となります。最後まで読んでいただいた方には感謝いたします。
「ColdFusionのすゝめ」は、初心者を対象にしています。初心者を対象にした意図は、ColdFusionの良さをわかってもらい、こらからもColdFusionを使い続けていただきたいとの思いからです。本連載がColdFusionをこれから学んで行こうという方にとってお役に立てたならば幸いです。