フォルダ／ファイル命名規則

• 複数単語をつなぐ目的で使われるスネークケース（snake_case）, ケバブケース（kebab-case）, キャメルケース（camelCase）などは、本来の意味を読み取りづらくする恐れがある。特に安易な命名の温床になりやすく、冗長になりがちであるため禁止とする。 また、フォルダ構成においては、階層化（下位フォルダへの分割）で意味を分ける手段があり、複雑な単語の結合は不要と判断している。
• ローカルを意図した、先頭への'_'(アンダーバー)の付与は禁止です。フォルダでなく、ファイルに付与して下さい。

• そのフォルダの意味を表す英字の名称を用いる。(英単語を推奨)
• 出来れば纏まりの中で一意となる事が望ましい。フォルダの配置の変更や名前空間を考慮しての事なので、それほど重要視する必要はない。尚、次の所属に関わる事ですが、一意でないと区別が出来なくなります。
• そのフォルダの所属(どのフォルダの下位か)を表すような名称にはしない。所属は配置で表せばよく、名前空間などで所属等を表したい時はそこでその様に名付ければよい。(それぞれの命名規則に従う必要はあります。)
• 成果物の出力先と置き場は分ける方が安全です。ツールによっては、フォルダごと上書きする物もあります。命名も注意しましょう。
• 詳細はフォルダ内のREADMEファイルを見れば分かるようにすれば良いので、簡素な名称にする。

index, README など、一般的にファイル名として意味のある物はそのまま付ける。 特別な命名規則を適用せず、一般慣習に従います。 これらは認識性とツール連携を重視するためです。 そのため、用途, 意味も一般慣習に合わせるので、拡大解釈に注意して下さい。

以下のファイルは、以下の名前とします。

• _common: 内部共通処理用(フォルダ内)の機能を集めたファイル
• _batch: 一括処理用の機能を集めたファイル

例: _namingfolder01.pug

スネークケース（snake_case） を採用する。ただし'_'(アンダーバー)での接続は１つだけとする。

例: naming.md, naming_folder.md, naming_folderfile.md (X: naming_folder_file.md, _naming.md)

スネークケース（snake_case） を採用する。これはデータ自身に説明を含めるのが困難な場面が容易に想像できるため、ファイル名で詳しく分かる必要があるとの判断です。 尚、英字小文字だけでなく数字の使用も自由です。

Pug, Sass などの言語形式でデータを保持する場合は、ファイル名にその旨分かるように命名する。 下記での接頭辞がない言語形式のファイルならデータであろうという推測も一応は出来ます。

• _: 部品の様な物は、先頭に'_'(アンダーバー)を付ける。 Sassのコンパイル対象外「パーシャル」の機能を意識して、後に参考にして他にも広げた規則です。
• risyu: 外部のファイルとの識別用です。
• gl: フォルダ区分を小文字で記しています。フォルダ区分はフォルダごと割り振られ、それによりどのフォルダか分かる様にしています。(プロジェクトで一意) 例示のglは、共通メンバのフォルダを表します。主にコンパイルエラーでのメッセージを読むのに役立ちます。
• xxxxx: そのファイルの意味を表す英字の名称を用いる。この部分は英字の小文字で、'-'(ハイフン) '_'(アンダーバー) などの使用は禁止です。文字数は任意ですが、短すぎず長すぎずを心がけたいです。
• nnn: この部分はバージョン管理用の数字です。実際にはバージョン管理は面倒なので、000の固定になると思います。 末尾を表す意味もあるので、省略は不可です。
  末尾を表す必要があるのと、拡張性を担保しないと、この規則が守れないという考えで末尾３桁の数字の部分を用意しています。
• ファイルのフィルタリング等も意識して、命名しましょう。

• 複数単語をつなぐ目的で使われるスネークケース（snake_case）, ケバブケース（kebab-case）, キャメルケース（camelCase）などは、本来の意味を読み取りづらくする恐れがある。特に安易な命名の温床になりやすく、冗長になりがちであるため禁止とする。 文書ファイルの名前で例外として、単語は２つまでの限定としてスネークケース（snake_case） を採用しています。
• 文書ファイルが例外の理由は、そこに「所属接頭辞」を用いていないからです。