Является ли начало имен с номерами плохим соглашением об именовании данных?

Моя компания использует ArcGIS и придерживается стандартов именования файлов проектов и данных, которые (по большей части) соблюдаются. Что меня всегда беспокоило в стандартах именования, так это то, что он обязывает начинать все имена проектов и файлов данных с номера проекта - восьмизначного числа . Я всегда считал, что присвоение имен ГИС-файлам, начинающимся с цифр, - это плохо, и процессы (особенно с GRIDS) не срабатывают из-за имени файла.

Я пытаюсь изменить корпоративные стандарты, чтобы отменить требование номера проекта, однако я не могу найти много документации о том, почему «числа в качестве первого символа» в имени файла - это плохо.

Кто-нибудь может указать мне правильное направление, насколько ресурсы для поддержки этого аргумента?

Это соглашение просто просит выявлять ошибки от плохих командных интерпретаторов . (Слишком легко спутать начальные цифры с числом.)

Успех вашего программного обеспечения во избежание таких ошибок сегодня не является гарантией того, что они не появятся в будущих выпусках. Это происходило много раз, в течение десятилетий, с программным обеспечением ГИС ESRI. Такое поведение широко освещалось и подробно документировалось. Вам не нужно заглядывать дальше, чем на собственные пользовательские форумы ESRI, которые датируются десятилетием. (Более глубокие поиски старых архивов спискового сервера вернут вас еще раньше, примерно к 1995 году.) Интересные поиски Google включают

Сайт "GRD ERROR": forums.esri.com

имя файла 8.3 сайт: forums.esri.com

Вместе они предоставят около сотни реальных примеров проблем, которые вызвали такие имена файлов и потенциально могут вызвать снова.

Избегайте чисел, если можете -

Науки о Земле имеет хороший пример http://library.oceanteacher.org/OTMediawiki/index.php/General_File-Naming_Convention_for_Earth_Science_Datasets#Filename_Sections_in_the_Order_They_Should_Appear

Пробелы могут сбить вас с толку - некоторые старые основанные на DOS команды для перемещения файлов прерываются, если пробел используется - разумно использовать «_» (подчеркивание) - это относится к рабочей станции ArcInfo - всего 8,3 (8 символов и формат файла) , В эти дни вы можете иметь больше - но сделайте его читабельным для доставки. избегать дат (большинство файлов имеют временную метку)

* В основном придерживайтесь этого утверждения Пример:

Правила соглашения об именах, согласно указаниям механизма Microsoft JET, который позволяет приложениям Windows, таким как ArcMap, читать различные форматы таблиц, включают следующее:

• Имя должно начинаться с буквы, а не с цифры.
• Имя не должно содержать пробелов.
• Единственный допустимый специальный символ - это подчеркивание.

ArcMap

Любое диалоговое окно «Открыть» или «Выбрать» файла будет выполнять сортировку, предполагая, что файлы названы по буквам. Поэтому, если вы используете восьмизначный (!) Уникальный номер для каждого проекта, сортировка файлов быстро станет нелогичной. Например

1
10
2
20
3 etc. 

Кроме того, будет много инструментов ГИС, которые по-прежнему будут принимать файлы, соответствующие формату имени файла MS DOS 8.3 .

Использование имен файлов в качестве ключа к проекту в лучшем случае кажется громоздким требованием. Было бы гораздо лучше хранить все файлы в какой-то системе контроля версий в соответствующих репозиториях проекта.

Похоже, что здесь нет ограничений на использование первой буквы в качестве цифры, кроме как здесь, в соглашении NPS.

Имена таблиц файлов и атрибутов
A. Конечные продукты ГИС - Покрытия, шейп-файлы и другие форматы должны соответствовать структуре имен файлов 10.3 (то есть cxxxxxxxxx.ext, где «c» - это буквенный символ, а «x» - буквенно-цифровой, для всего 13 символов и один период, отделяющий имя файла от расширения). Следующие соглашения должны использоваться для генерации имен файлов: ccccccc99c.ext
i. 4-значный префикс для кода парка (см. Таблицу 1).
II. 5-символьный код проекта, указанный в базе данных отслеживания проектов NCCN. См. Информацию о проекте отслеживания NCCN (NCCN 2005b, в разработке).
III. Отдельный символ, дифференцирующий ГИС-слои в одном проекте. Этот единственный символ называется кодом продукта проекта ГИС и поддерживается в базе данных отслеживания проекта NCCN. Это должен быть алфавитный символ, выбранный последовательно (т. Е. Начинаться с a, b, c и т. Д.), Поскольку для ГИС создаются или добавляются дополнительные слои ГИС. Например, предполагая, что для этого проекта уже существуют два других ГИС-слоя, файл экспорта ESRI Arc / Info начальных точек разреза проекта NOCA Landbird Inventory будет иметь имя файла «nocabda02c.e00».
Iv. Расширение Шейп-файл ESRI должен состоять как минимум из пяти файлов с одинаковыми именами и следующими расширениями: .shp, .shx, .dbf, .shp, shp.xml и .prj. <<

Извините за вышеприведенный абзац.
Мой опыт показывает, что, когда существует нестандартное соглашение об именах,
1. люди нарушают его из-за трудностей с присоединением.
2. люди нарушают его, чтобы придерживаться других стандартных соглашений об именах.

Дело в том, что существуют инструменты, которые не допускают имен файлов и имен полей из первых символов, и именование СУБД почти всегда следует этим же правилам.

Indiana документация
Oregon документация
Jason Birch документация
Nat Park Serv документация
общественной безопасности межведомственный документация
коды участка реки , кажется, игнорирует лучшие практики
Сан - Антонио документация
Более NPS документация