管理しやすい分類情報付きファイル名を使おう

アプリを開発するとき、ソースコードだけでも何個ものファイルを作るでしょう。その名前(ファイル名のことですが)を、どのように付けていますか。機能を表す言葉を名前に付けるのは当然として、他に何か工夫してますか。

アプリの規模が大きくなるほど、ソースコードのファイル数が増えます。多くなったファイルを管理するために、どのような工夫ができるでしょうか。いろいろな工夫が考えられる中、今回はファイル名を使った工夫を取り上げてみます。

実は今まで、ファイル名の命名ルールに関してだけでも、何度かの改良を加えてきました。使用するOSや言語や開発ツールによっても異なるため、次々に良くしていったわけではなくて、使用環境ごとに合わせながら変えてきたわけです。ここで紹介するのは、Xcode+swiftという開発環境に合わせた工夫です。それでもオブジェクト指向の言語に共通する工夫だと思いますから、考え方は参考になるでしょう。興味のある方は読んでください。

　

ファイル管理のために、ソースコードのファイル名を工夫する方法では、ファイル名に分類情報を含めることで実現します。分類情報といっても、難しいことではありません。私の場合は、大まかな種類を示すために、先頭の２文字に役割を持たせるのが中心です。

具体的には、ファイル名の先頭に２文字の略号を加える方法で実現しています。実際に使っている略号は、今のところ、以下の５種類です。

// ファイル名の先頭に付ける主な分類情報
・AC：特定の条件(装置など)に依存する共通ライブラリのクラス（複数アプリで利用）
・BC：共通ライブラリのクラス（複数アプリで利用）
・BP：共通ライブラリの関数や定義値など（複数アプリで利用）
・MC：アプリで使うモデルのクラス
・VC：アプリで使うビューのクラス

見て分かるように、上から３つが自作の共通ライブラリで、どのアプリにでも使えるように作っています。何かのアプリを開発し始めたとき、必要なものを選んでプロジェクトに追加します。もちろん、開発途中に追加することもあります。

「BC」は、日付処理やファイル処理といった共通機能を、クラスとして実現したライブラリです。続く「BP」は、クラス以外の形で実現した共通ライブラリです。UI部品の生成関数や、目的別の色定義など、どのアプリでも使いそうな内容を入れています。

「AC」は、どのアプリでも共通に使えるライブラリの中でも、特定の装置に依存するとか、特定の環境だけで動くとか、何かの条件があるものが対象です。以前に紹介した、小型プリンタRoltoを制御するクラスなどが、この分類に入ります。

下から２つが、アプリごとに作成するクラスです。「MC」は、扱うモデルごとに作るクラスで、「VC」は、表示する画面ごとに作るクラスです。複数のモデルを使って、印刷用のレイアウト画像を生成するクラスなどは、「MC」に入れます。

５つのうち４つが、クラスとして作成するソースコードです。各ソースコードの中には、大きなクラスだけでなく、関連する小さなクラスも入れます。小さなクラスを独立したファイルとして保存すると、数が急激に増えてしまいます。それが嫌いなので、ファイル数を増やさないようにと、関連するものは一緒に入れています。

　

先頭に略号を付けるという話だけでは、どんな感じなのか想像しづらいでしょう。ということで、実際のファイル名に使った場合の例を挙げてみます。長くならないように、一部を抜粋した感じのファイル名一覧です。

// ファイル名一覧の一例(抜粋版)
・AC_Print_Net.swift
・AC_Print_Rolto.swift
・BC_Date.swift
・BC_DrawCG.swift
・BC_Files.swift
・BP_Base.swift
・MC_Pref.swift
・MC_Products.swift
・MC_Sales.swift
・VC_Env_Brows.swift
・VC_Env_Manag.swift
・VC_Main.swift
・VC_Pref_Edit.swift
・VC_Prod_Edit.swift
・VC_Sales_Brows.swift
・VC_Sales_Edit.swift
・VC_Sales_Graph.swift
・VC_Sales_Input.swift

見てのとおり、ファイル名を並べただけでも、きっちりと分類されている感じに見えます。また、先頭に付けた略号の変わり目では、非常に弱くですが、水平の区切り線があるようにも見えます。もちろん、そのような効果も狙っての命名ルールなのです。

先頭の略号に続けて、半角のアンダースコアを入れています。この１文字が、全体を見やすくするとともに、区切り線が見えるようにもしているのです。ファイル名の中に入れた２番目のアンダースコアも同様で、言葉の区切りを明確に見せています。

　

ファイル名の付け方では、先頭の略号以外にも、いくつかのルールを決めています。まず、名前を長くしないことです。短くて内容が推測できるように、長い言葉は略して付けるように決めています。

先頭の略号以外では、２段階の分類としての役割を持たせています。とくに画面ごとのクラスは、同じデータを扱いながら、入力用や閲覧用やメンテ用などの複数画面を作ります。それらの画面を区別しながら、同じデータを扱うことも表さなければなりません。扱うデータの種類を中分類に、役割の違いを小分類として命名すれば、先頭の略号を大分類として、３段階の分類階層が実現できます。

こうした階層による分類は、Xcode以外でファイルを扱うときにも役立ちます。Xcodeのプロジェクト上では、好きな並び順に動かせますが、Finderなどのファイル管理ソフト上では、ファイル名による並び順に変わります。そんなときも、階層で分類したファイル名なら、きっちりと区分けされた形でファイル名が並ぶのです。オープンダイアログでも同じで、探しているファイルが見付けやすくなります。

３階層の分類を使うのは、おもに「AC」と「VC」です。「AC」では、中分類に「Print」と付けることで、印刷関係のクラスだとが表現できます。「AC」での中分類は、共通ライブラリとして決まった言葉を用いることが大原則です。もう一方の「VC」では、中分類にモデルの種類を付けることで、１つのモデルを扱う複数画面を１つに束ねられます。また、どの「MC」と関係しているのかも明確に表せます。複数のモデルを扱う「VC」の場合は、複数のモデル名を短縮して、中分類に入れることになります。

複数ある「VC」の中でも、「VC_Main」だけは特別です。名前から分かるように、最初に表示される画面です。最初に表示されるわけですから、アプリ全体に関係する初期処理なども入れます。また、アプリで使う共通の定義値なども宣言します。これらを別に分けても構わないのですが、メイン画面に入れることで、初期処理中に何か重大なトラブルがあった場合に、トラブル内容の細かな表示が作りやすいメリットが生まれます。

今までやったことはないのですが、外から持ってきたソースコードのファイルを追加する場合のルールも決めています。そのようなファイルは名前を変えずに、元のまま追加するだけす。先頭の略号が付いていないことで、自分が作成したソースコードではないと区別できます。また、元のままのファイル名を残すことで、どこから来たのか探しやすくもなります。

　

先頭に付ける略号が、今の形に決まるまでは、何度か変更がありました。XcodeとSwiftを使ってアプリを作っていく中で、前に使っていたルールを変更しながら、今は上記の形になりました。つい最近のことです。

少し前までは、「AC」と「BC」の区別はなく、どちらも「ZC」としていました。また「BP」は、「ZZ」としていました。「Z」で始まる言葉が少ないので、ライブラリは「Z」で始めるのは良いかなと考えてのことです。でも、先頭に付ける略号なので、一般の言葉との重複を気にする必要はないと考え始めました。そこで、「Base」の頭文字を使った「B」に落ち着いたという流れです。「B」から分離した「A」は、名前でソートしたときに「B」の近くに並ぶ言葉を探し、思い浮かんだ「Add」の頭文字から取りました(深い意味はありません)。

このブログの何回か前に、「ZZ_Base」という記述が出てきたと思います。今は「BP_Base」に変えています。ようやく今回の形で、一応落ち着いたかなという感じですね。今後は、大きく変えないでしょう。略号の追加はあると思いますが。

　

Xcode上で作るswiftソースコードのファイル名は、クラス名と同一にする必要はありません。それよりも、自分が使いやすい(または管理しやすい)名前をつけることで、間違いを少しでも減らしたり、再利用する際に扱いやすくするほうが大事でしょう。そのような視点でファイル名の付け方を考えると、いろいろなアイデアが出てくるのではないでしょうか。この機会に、ファイル名に加える分類情報を考えて、自分なりに扱いやすい命名方法を見付けてください。