ファイルの命名と整理のルール

2003/03/05 西田顕郎 / 2009/05/12 奈佐原顕郎 / 2010/09/10 奈佐原顕郎 / 2023/08/17 奈佐原顕郎

　計算機上で大量のデータファイルを扱う場合、効率を大きく左右するのがファイルの命名規則や整理方針である。しかしそれらについて一般的なルールや教育文化はほとんど存在しないので、我々は各自で独自に試行錯誤しながら良い方法にたどりつこうとする。これは明らかに無駄だ。すくなくとも大学の卒業研究などで、こういう観点の教育が必要である。

ファイルの命名規則

簡潔

　ファイル名は、十分な情報を含むならば、なるべく短いほうがよい。それだけでも管理の手間が省ける。たとえばCUIの場合、コンソールでファイル名を長々と打ち込むのはつらい。間違いを起こしやすいし見付けにくい。タブキーでファイル名の入力補助をしてくれるbashやtcshのようなシェルでは楽だが、それでもコンソールの1行をはみ出るくらい長いファイル名の場合、コピー・ペースト時に無用の改行などが挿入されかねない。

一意性

　一意性とは「同じファイルには誰が判断しても1つの名前が定まる」ということ。世の中の全ての人に強制できるルールを我々が作ることはできないが、少なくとも我々のローカルルールに従えば、ひとつのファイルに異なる複数のファイル名を考案することはできない、という点が重要である。ユーザーが自分一人であっても、半年たてば記憶が薄れて当時の作業を細かく思い出すのは難しい。プログラムやスクリプトを組みながら「あのデータファイル、なんて名前だっけ...」と思って調べ直すことが効率を下げる。どのディレクトリにしまったか忘れたような場合は検索をかけることになるが, そもそもファイル名がわからなければ検索しようがない。

一義性

　一義性とは「ひとつのファイル名が異なるファイルにつくことがない」ということ。ファイル名を見ただけで、そのデータがどういうものか、曖昧さが無く判断できるということだ。これが無いと, 似てるけどどこか違うみたいな複数のデータが同じファイル名を持ってしまう。これをファイル名の衝突という。ファイル名の衝突が起きると一方が他方を上書きしかねない。別のディレクトリに別離すれば衝突は回避できるが, どちらをどう扱えばよいかいちいち判断しなければならない。

配列順

　これは時系列のデータに特に言えることだが、ファイル名の一覧がなるべく解析処理の順番になって現れるようにすることが重要である。たとえば年号を西暦の下2桁だけで表してしまうと1998、1999、2000、2001、2002の各年のデータを時間順に並べた場合に00、01、02、98、99という順になって、2000年以降のデータが前に出てしまう。プログラムでケアできる問題ではあるが、逆にいえばケアしなければならない問題を発生させているわけで、これもミスや非効率の原因となる。

汎用性

　大量のデータ処理に使われるのはほとんどがUNIX系のシステムだが、デスクトップでの編集作業でWindowsやMacも使われる。これらのシステム間で、しかも多国籍言語間でもトラブル無くデータを管理/流通させるための汎用性が重要である。
　最近はどのシステムでも、アルファベットの大文字と小文字をファイル名で区別できるようになりつつあるので、大文字/小文字の使い分けは可能だろう。漢字やカタカナ、半角カタカナなどは異なるシステム間はおろか、同一のシステム内でも設定によっては面倒なことをひき起こすので使用は避けた方がよい。どうしても必要な場合は、文字コードをUTFに統一する(WindowsではSJIS、古いUNIXではEUCが一般的なので、悩みどころである)。
　また初心者にありがちだが、せっかく英数文字で命名しても全角の英数字を使ってしまう場合がある:
例: ２０１０＿０５３１＿dsc00842.jpg ... ダメ
例: 2010_0531_dsc00842.jpg ... 良い
　これでは漢字やカタカナを使っているのと同じだ。初心者には全角と半角の違いを、意味も含めて教育すべきだ。
　ファイル名の中にスペースを使うのはダメである。ファイル名にスペースがあると、コマンドで操作するためにいちいちバックスラッシュでエスケープしなければならない。ファイル名をawkなどでテキスト処理する際も面倒だ（awkは標準でスペースを区切り文字と認識する）。そのようなファイル名をもつファイルがディレクトリ内にひとつでもあると処理のエラーの原因になる。ファイル名をわかちがきするにはスペース以外にはハイフンやアンダーバー、ドットなどが使われる。ドットは拡張子のはじまりという特別な意味を持つので使用に注意が必要である。ハイフンはデータ名を算術演算にも用いるような場合(たとえばGRASSなど)、マイナスの記号と衝突してしまいエラーを起こす。アンダーバーはそういった問題が無いため, 無難であり適切である。しかし使い慣れていない人にはアンダーバーがキーボードのどこにあるのかを教えなければならない。

慣習

　以上のようなことは、多くの人がそれぞれに考えていることであり、統一的ではないにしても、ある程度常識的な慣習が存在する。それらはもちろん完全でもないし矛盾も多いが、そういう慣習には敬意を払う必要がある。というのも, 慣習をまったく無視したルールは誰も使ってくれないし、外部から取得したデータの名前は多くの場合、慣習的であり、それを我々のローカルルールと整合させることに多くのコストが必要ならば、それは効率的とは言えない。

提唱ルール(Ver. 0.1)

　以上のことがらは、多くの場合、互いにトレード・オフの関係にある。特に、多くの事柄と対立するのは簡潔性である。従って、「完璧な」ルールは存在しない。それを踏まえた上で、あえて以下のようなローカルルールを提唱しよう：

1. 使用可能な文字：英数半角ASCII文字。記号はハイフン、ドット、アンダーバー、プラスのみ。
2. 時間・場所・項目・バージョン・フォーマットの順に記載し、それぞれをアンダーバーでわかちがきする。
3. 時間は西暦・月・日・時刻の順とし、西暦は4桁、月は2桁の数字、日も2桁の数字とする。お互いの間は、西暦と月の間と日と時刻の間だけをアンダーバーでわかちがきする。日をDOY (day of year; 1月1日からの通算日)で書く場合、123のように、3桁の数で記載。DOY99以下は099のように0で位取りをする。
4. 場所は固有名詞の場合、先頭を大文字、以下を小文字にする。略称は全て大文字で書き、大文字の間に略称を示すドットは入れない。
5. 項目も、略称の場合は全て大文字。略称以外で数語にわたる場合はわかちがきにせず、各語頭を大文字にしてわかちがきの代用とする。略称どうしが連続する場合はアンダーバーでわかちがき。
6. READMEファイル： 命名規則にローカルルールを導入する場合は、そのローカルルールはあるディレクトリ以下のツリーにのみ適用し、そのルートのディレクトリにREADMEファイルを設けて、ローカルルールを記載する。記載は英語で書く。日本語で併記してもよいが、あくまで併記である。
7. 変えないこと: いちど決めたファイル名を後で変更するのは, 大きな混乱の元になる。特に、ドッペルゲンガー症候群（似たようなファイルが複数発生し, どれが正統なのかわからなくなる現象）の危険性が大。

例

* プレゼンスライドは他の発表者のスライドと混ざってしまう可能性があるので、あえて発表者名をファイル名に入れるようにしている。

ファイル整理のルール

オリジナルデータと中間データを明確に区別すること。

　実験や観測といった活動から直接的に回収されたデータをオリジナルデータと呼ぶ。ここから様々な処理（補正や単位換算、統計処理等）が行われて, 実際に使えるデータになり、さらにそれが図表になってプレゼン資料や論文になる。そうした一連の処理過程において、オリジナルデータは、全ての根源であり最上流であり、最も重要な存在である。解析処理のどこかに不手際があったら、オリジナルデータまで遡って解析をやり直さねばならないこともある。従って、どのような解析においても、そのオリジナルデータに遡れるように整理しておかねばならない。従って、オリジナルデータは、誰の目から見ても、解析途中のデータ（中間データ）や最終的な図表等（出力データ）と混同しないように工夫しなければならない。それを怠ると, いくつもの中間データとまぎれてしまって、どれがオリジナルデータなのかわからなくなってしまう。

　オリジナルデータを区別する工夫としては, ファイル名にオリジナルデータであることを明記する識別記号を入れるという手もあるだろうが、最も簡単なのは, originalという名前のディレクトリを作って, そこに入れることだ（もちろん, そこにはオリジナルデータとそのreadmeファイル以外を入れてはならない）。

ドッペルゲンガー症候群に気をつけること。

似たようなファイルが複数発生し, どれが正統なのかわからなくなる現象。野口悠紀雄「超整理法」参照。

ディレクトリはあまり深く掘らないこと。