FileMaker の フィールド名 や テーブル名 の 命名規則 とかの話

FileMaker の フィールド名 や テーブル名 の 命名規則 とかの話

こんにちは。solb system の Teruhiro Kömaki です。

そろそろ、新しいバージョンの FileMaker 14 でますかね〜?ちょっと楽しみですね〜

それはそうと、4月初旬からFileMakerの講座がアビバで受講できるみたいですね!
今後は、どのような展開になっていくんだろうか?って楽しみに見ています!

【関連】新講座「FileMaker® Proベーシック」を4月より全国100拠点以上のアビバにて開講、3月20日に販売開始 – 報道発表資料 – FileMaker

【関連】新講座「FileMaker® Proベーシック」を4月より全国100拠点以上のアビバにて開講、3月20日に販売開始|ニュース|Link Academy Inc.【株式会社リンクアカデミー】

FileMaker講座の詳細(2015/03/12時点)
講座名 FileMaker Proベーシック
受講回数 10回(1回90分)
受講期間 2ヶ月
受講料 60,480円(税込)

個人の方やインハウスの開発者の方をはじめとして、FileMakerの開発ができる人材が増えていくってことは、良いことだと思います。

けどFBAさんがやってるトレーニングと重なるような気もするけど、どうなんだろう?講師はどうなんだろう?ひじょーに楽しみです。

本題の前に、命名規則や開発効率とかメンテナンス性を高めるって話の際に同じように話題になるのが、記法やプレフィックスやハウスキーピング【Housekeeping】ですよね!
興味がある人は、いろいろと調べてみてください。
(記事の下のほうに関連リンクありますので)

あと、命名規則って言い方じゃなくて【コーディング規約】とか【ネーミング規約】とか人によって言語によって色々と解釈や意味が違うと思いますが、今回は細かく掘り下げないです。

話をもどしまして、今回はFileMaker の フィールド名 や テーブル名 の 命名規則 とかの話ということで、ちょろっと書いてみます。

命名規則とは

FileMakerと命名規則というキーワードに興味があったり、調べたりしてる人は

  • ESS(External SQL Data Source)を使う必要のある方
  • 開発効率を意識してる開発者の方
  • FileMakerではない言語をメインに使ってる方
  • 複数人での開発を考えてる方
  • 脱自己流を考えてる方

とかじゃないかなって思います。

因みに、命名規則のことを英語で【FileMaker Naming conventions】などと検索すると、いろいろとヒットしますので、よければチェックを。

【関連】FileMaker Naming conventions – Google 検索

だから、そういう人の場合を考えると、説明は不要なんですが、いちおー。ってことで。

【関連】命名規則 (プログラミング) – Wikipedia

命名規則とは
プログラミングを行う際に識別子の名称となる文字列を決定するためのルールを定めたもの。ネーミング規則、ネーミング規約、命名規約とも呼ぶ。

通常は、ソースコードの可読性や視認性の向上、プログラミング効率の改善などを目的としている。

命名規則は、プログラミング言語の仕様、メモリサイズ等のハードウェア的な制約、エディタや IDE の機能などに影響を受けていることがある。

命名規則を決めたときの利点
命名規則を決めた場合の潜在的利点としては、以下のものが挙げられる。

識別子の使用法に関して追加情報(メタデータ)を名前に含める。
開発チーム内で命名について一貫性を持たせる。
リファクタリングを自動化したり、検索置換ツールで間違える可能性を減らす。
潜在的な曖昧さを回避し、違いを明確化する。
成果物に美しくプロフェッショナルな見た目を与える(長すぎる名前、かわいい名前、面白い名前、略語を排除するなど)
複数のチームが開発したものを統合するような場合に、名前がかち合うのを防ぐ(名前空間参照)。

課題
命名規則の選択とその実施は、論争になりやすく、各人がどんな命名規則が最善かについて意見を持っていることが多い。

さらに、よく知られている命名規則を採用したとしても、全体に実施を徹底させることができなければ、一貫性がなくなり、混乱が生じる。

このような課題は、その命名規則が一貫しておらず、記憶しづらく、利点よりも欠点が多いような場合には、さらに悪化する。

もはや、ほとんどの部分を言っちゃってますが。
「ちょっとまて、おにぃーさん!」って感じ w

また、タイトルには、フィールド名やテーブル名って書いてますが、命名するときの全般的な規約とかメリットについて取り上げますので。

Wikipediaにも書かれてますが、人それぞれの考えがあるし、普通のことだと思うので、そういうのもあるねーって感じで受け取ってもらえれば。

気づいたら加筆していくと思います。

あと、みなさんの意識してることを教えて頂けたらうれしいので、気軽にコメント頂きたいです!

関連リンク

検索するといっぱいでてきますが、関連リンクを張っておきます。

まずは、FileMakerの命名規則(コーディング規約)といえば、これでしょ!というくらい有名なオフィシャルのデータです。
File、Table、Field、Layoutなどの規約が記載されていて、背景も書いてますので確認してみてください。

【関連】FileMaker Development Conventions[pdf]

  • File naming
  • Table naming
  • Field naming
  • Table Occurrence naming
  • Layout naming
  • Calculation documentation and formatting
  • Value list naming
  • Custom Function documentation and formatting
  • Account naming
  • FDC adherence documentation

【関連】[sevensdoor.com] – FileMakerの開発者向けresourceサイト

(3)「自分流」開発手法ですいすい構築
データベースに限らず、じっくり設計したうえでモノ作りを始め、以後は具体化作業に専念するパターンが多いようです。FileMakerの場合も、本来ならばそのように、一般的なメソッドに従って取り組めば、効率的な開発ができるのではと思うのですが、「走りながら次の手を考える」ことが可能なFileMakerゆえ、どうしても目先の戦いに意識が集まりがちです。何とかソリューションは完成したけど、半年後に機能を追加しようと思ったら「???…」全く思い出せないってことありませんか。

要は自分なりのパターンをしっかり作り、常にそのパターンをトレースすることで開発中にも迷わない、1年経ってもまだ迷わない。中身を見ただけでどういった処理をしようとしているか読み取れるようにしようというお話です。

コメント漬けにすべし。
・スクリプトの冒頭にとにかく目的から処理の内容まで書いてしまう。
・スクリプト内には、処理ごとにコメントを付け、区切りと説明を兼ねる。

命名は自分流で、首尾一貫させること
・サブスクリプト名の一文字目は必ず特定の文字にするなど、他所から呼ばれるものと一目で分かる工夫をする。
・フィールド名は名前順ソートを考慮するとかえってデメリットが多い。いろいろやるうち結局はカスタム順位になってしまうので「読んで判る名前」にしておく方が無難。

最近の傾向としても、名称が長くなることのデメリットよりも、読めば判る事のメリットを優先する方向、とのこと。命名規則のパターンは伸びてきてるんですね。各方面でソリューションの高度化、複雑化が進んだことの現れかもしれません。
自分流を貫くって言いますが、それは問題の出口が見えているからこそ、そこへ至るためのコース取りを選べるわけで、暗中模索の場合は難しいかもしれません。いや、自分の事情を思い出してるだけですけど。

【関連】FileMakerの実装サンプルとしてFMCon2Go11.fp7を読む | FileMakerを考える

「__kp_」と「__kf_」
これらは恐らく、PKとFKを指しているんだと思いますが、文字の順序が入れ替わってるのは、ソートを考慮しての事でしょう。
面白い点も幾つかあります。SpeakerのPKが「__kp_SPK_ID」と略記されているのは、キー名が長いと不便があるからかと思ったんですが、Sessionテーブルでは略されていません。
その「__kp_SPK_ID」が、シリアル値の自動入力になっているんですが、番号に「JPN」のプレフィックスを付けています。DevCon用ファイルをベースにしているので、混同を防いだり、場合によっては混在を許容したりする為の処置でしょうか。
UtilityのPK「__kp_Utility_ID」も自動入力ですが、「D2G」のプレフィックス付き。多くのフィールドがグローバル格納なのであまり必要に見えませんし、恐らくこのファイルではあまり生きていない工夫のようですが、設定値などをグローバルに持てない場合に、レコードを決め打ちするためのPKを設けるなど、理由があるのかも知れません。

【関連】命名規則について – Google グループ

【関連】FileMaker Development Conventions[pdf]

【関連】Naming Conventions – Coding Standards – FileMaker Coding Standards

【関連】Linear Blue’s FileMaker Coding Standards

【関連】Linear Blue coding standards & examples[pdf]

【関連】FileMaker Field Naming Convention | Extensitech

【関連】FileMaker Naming Conventions and Standards | DB Services

後半は海外のサイトですが、余裕があれば頑張って見てみましょー。

命名規則を決めることの意味

なんだかんだいって、最終的には開発効率の向上と保守性の向上に繋がると思います。

  • 可読性の向上
  • 保守性の向上
  • ファイル(テーブルオカレンス、フィールド、レイアウト、スクリプトなど)を見れば、設計思考や意図が第三者に分かるようにするため(設計書などのドキュメントがなくても)

こんな感じだと思います。たとえば、テーブルオカレンスを見たときに

「テーブルA」と「テーブルA 2」

というのを見ると「ちょっとまて、おにぃーさん!」状態になりますよね。
ファイルが小さければ、まだよいのですが「どんだけ分かりづらいだんだよ!」と突っ込みたくなるファイルは、多々ありますしね。。。

たとえば、Javaの場合(Java コーディング規約 2004)をみると

◇見やすさを重視せよ
「良いコード」の基本は、「他の人が読んでもわかりやすいと感じられるコード」と言えます。コードの見やすさは、 フォーマットはもちろん、ロジックの簡潔さや API の常識的な使い方などから生まれます。コーディングにあたって は、常に他の人の視点を意識しながら、見やすさに気を配って記述しましょう。 また、自分で記述したコードであっても、しばらくたってから読み返してみると理解に時間がかかった経験はないでし ょうか。「3 日前に書いたコードは他人のコードと同じ」ということも言われます。見やすさを重視することは、他の 人のためだけでなく、自分のためにもなります。

ということで、FileMakerは自由奔放に作っても動きますが、せっかくなら名前の規則性はつけましょう!と思います。

そして、せっかく名前の規則性を考えるのであれば英語にしましょう!

おまけですが、英語といっても、日本語のローマ字表記は避けることにしています。
ローマ字は1文字ずつ追っていかないと意味が分からないこと、また、ローマ字は長音や拗音の表記にバラつきがでやすいためです。英単語の場合はパッと見れば意味が分かります。

だけど、英単語化が嫌だ!っていう人もいると思います。
例えば、英単語はスペルが長くなるから、似たような英単語がでてきた場合に選択がむずいから、業務で使う用語に該当する的確な英単語が当てはまらない場合があるから。

いろんな意見があると思いますが、私としては、スペルが長くても意味の分かる名前をつけるようにしています。業務で使う用語も、用語集にまとめれば問題ないと思います。

なぜ英語にするべきなのか

こんな感じでしょうか。少し無理矢理な感じもありますが。

  • ESSやODBC/JDBCを使う場合に、2バイト言語に起因するエラーがあるから
  • カスタムウェブを使う場合に、文字コードを考慮する必要があるから(日本語じゃなくても、考慮するんですけどね。)
  • スケールを考えて、サーバーのレプリケーションを構築する場合などに、サードパーティーのツールやソフトで2バイト言語が使えない場合があるから
  • 日本語を使う理由が見当たらないから
  • 開発効率の向上のため

気をつけること

名前をつけるときに、気をつけることも書いてみます。

  • 記号は最小限にする
  • 機種依存文字は使用しない
  • スペース(全角、半角)は使用しない
  • アルファベットから開始する(数字から開始しない)

開発効率の向上とメリット

では、どのように開発効率が向上するのか。って言われると、こんな感じでしょうか。

  • ソートが気持ちいい
  • メンテナンスが簡単になる
  • テーブルやフィールドを選択しやすい
  • テーブル名やフィールド名から意図がわかる
  • インポートの際に分かりやすい
  • ハードコードせずに、取得関数やグローバルフィールドを使い、適切にモジュール化し再利用することで、フィールドもスクリプトも最小限で実装できる
  • 最小限にすることで、管理する対象もコンパクトになり、全てに対する工数が減る
  • 「使っていないフィールドや、意図が不明なスクリプトがあるが削除できない」という状態を無くすことができる
  • 自分のルールがあれば、設計書を見なくても、ある程度の概要を思い出せる
  • 第三者が見ても分かりやすくすることで、結果的にお客様のためにも自分のためにもなる
  • (たとえば)レイアウト名に規則性があれば、レイアウト切り替えで「レイアウト名」を選択してなくてよい
  • (たとえば)フィールド名の規則を作り固定化すると、どのテーブルにいてもGetFieldで値を取得できる

例えばこんな感じ

例えばってことで、のせてみますね。

テーブルを選択する時

テーブルの選択時に、このようにソートされますので、関係性も分かるし選択しやすいですよね。

filemaker-naming-convention-field-table-02

因みに、私は「アンカーブイモデル」でこのように配置しています。
テーブル名をアンダースコアでつないでます。リレーションの関係性が分かりやすいと思います。
ただ、リレーションの階層が深くなると、テーブル名のスペルが長くなるので、テーブルを短い単語で略して表記するというケースも多いです。

filemaker-naming-convention-field-table-03

フィールドを選択する時

フィールドの選択時に、フィールド名をタイプすれば、瞬時に該当のフィールドに移動するので、スクロールするよりも選択しやすいですよね。

IDを選択している状態ですが、Noteを選択したい場合に「No」とタイプすれば

filemaker-naming-convention-field-table-04

このように、瞬時に移動するので、スクロールするよりも早いと思います。

filemaker-naming-convention-field-table-05

インポート時のフィールドのソート

フィールド名を英語にしておけば、A〜Zで確実にソートされますよね。当たり前ですけど。

filemaker-naming-convention-field-table-06

GetFieldで値を取得できる便利さ

GetFieldに限ったことではないですが、頑張ってハードコードしなくてもいいんじゃないかって思います。
値や定義が固定化されていて変化することがないなら、ハードコードしても良いと思いますが、場合によっては動的にした方がよいと思います。

どのテーブルでも同じフィールド名で設定しておくことで、プライマリーキー(この場合 _kp になります)を、下記のようなスクリプトで取得できます。

Userテーブル

filemaker-naming-convention-field-table-07

Logテーブル

filemaker-naming-convention-field-table-08

_kpの値を取得する場合

変数を設定[$TableName; 値:Get ( レイアウトテーブル名 )]
変数を設定[$kp; 値:GetField ( $TableName & "::_kp" )]

長くなってしまい、雑な感じになっちゃいますが、規則をもうけることでメリットは多いと思いますけど。

サンプルファイル

今回はサンプルファイルをありませぬ。

関連リンク

【関連】code – 識別子の命名規則(記法)の種類について – Qiita

【関連】[ThinkIT] 第3回:ネーミング規約(前編) (1/3)

【関連】ITエンジニアのスキル向上ゼミナール – 【中級】生産性と保守性を高めるコーディング規約の実際(前半) 規約の重要性:ITpro

【関連】ITエンジニアのスキル向上ゼミナール – 【中級】生産性と保守性を高めるコーディング規約の実際(後半) 規約の具体例:ITpro

【関連】キャメルケースよりスネークケースで。 – 偏見プログラマの語り!

おわり

せっかくなので、記法についてとか、もっともっと色々と書きたかったんですけど、またの機会にします!
少しでもプラスになれば幸いですけど、こういうのって無理にしなくてもいいかなとも思います。
特に自己流の「自分のやりかた」がある場合は、体にしみこんでると思うので、それを変えるのは大変かなって思うし、非効率になってしまうこともあると思う。
無理せずに少しづつ変えていけばよいと思いまーす。
あと、FTS応用のサンプルファイルを見たり、海外サイトのサンプルファイルを見ると、色々と勉強になります。

FileMakerを勉強したい人へ

FileMakerをしっかりと勉強するのであれば、オフィシャルの学習用テキストが一番確実です。

体系立てて習得できるので、断片的に勉強するよりも理解もしやすいはずです。

ということで FileMaker Training Series をやるべし!

FileMaker Training Series には基礎編応用編の2種類があります。

さらに FileMaker Training Series に近いのですが、もうひとつ別で FileMaker Drill Book というテキストがあります。

まずは、オフィシャルの学習用テキストを購入して、コツコツ勉強することが一番の近道だと思います。

少しでもお役に立てたことがあれば シェアしていただけると嬉しいです

via PressSync

FileMakerの開発を主なる仕事にしてます。 FileMakerのBasicなことやAdvancedなことをメインに記事を書いてますが、FileMakerに関係ないこともバシバシ書いていきます。 現在は Java 勉強中ですので、勉強会などにも参加していきます。 コメント頂けると嬉しいです!

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください