以数字开头的名称是不好的数据命名约定吗？

我公司使用ArcGIS，并且已经制定了项目和数据文件命名标准，并且（大部分情况下）遵循了该标准。东西一直困扰着我约他命名标准是，它的任务首先是项目数的所有项目和数据文件名-八位数。我一直认为，以数字开头命名GIS文件是一件坏事，并且由于文件名的原因，使进程（尤其是GRIDS）失败了。

我正在寻求修改公司标准，以降低项目编号的要求，但是，在文档中找不到关于为什么文件名中的“数字作为第一个字符”是一件坏事的方式。

在支持该论点的资源方面，有人能指出我正确的方向吗？

这个约定只是乞求从错误的命令解释器中找出错误。（将初始数字与数字混淆太容易了。）

您的软件今天在避免此类错误方面的成功并不保证它们不会出现在将来的版本中。数十年来，使用ESRI的GIS软件已经发生了多次。此行为已被广泛报道并充分记录。您无需再看十年前的ESRI自己的用户论坛了。（对旧列表服务器档案的更深入搜索将使您回到1995年之前。）有趣的Google搜索包括

“ GRD错误”网站：forums.esri.com

文件名8.3 site：forums.esri.com

这些加在一起将提供大约一百个此类文件名已引起并可能再次引起的问题的实际示例。

如果可以，请避免使用数字-

地球科学有一个很好的例子 http://library.oceanteacher.org/OTMediawiki/index.php/General_File-Naming_Convention_for_Earth_Science_Datasets#Filename_Sections_in_the_Order_他们_应该_出现

空格可能使您绊倒-如果涉及空格，一些用于移动文件的基于DOS的旧命令会中断-使用“ _”（下划线）是一个明智的想法-起源于ArcInfo工作站-仅8.3（8个字符和文件格式） 。这些天，您可以拥有更多-但使交付时易于阅读。避免日期（大多数文件都带有时间戳）

*基本上遵循此语句示例：

在Microsoft JET引擎的指导下，命名约定规则包括以下内容：允许Windows应用程序（如ArcMap）读取各种表格式，这些规则包括：

• 名称必须以字母开头，而不是数字。
• 该名称不能包含空格。
• 允许的唯一特殊字符是下划线。

ArcMap

假设文件使用字母命名，则任何“打开”或“选择”文件对话框都将进行排序。因此，如果您对每个项目文件使用唯一的八位数字（！），那么排序将很快变得不合逻辑。例如

1
10
2
20
3 etc. 

此外，还有许多GIS工具仍将假定文件符合MS DOS 8.3文件名格式。

使用文件名本身作为项目的密钥充其量似乎很繁琐。将所有文件以某种版本控制存储在相关项目存储库中会更好。

除此处的NPS约定外，似乎对第一个字母数字的约定没有限制。

文件和属性表名称
A. GIS最终产品– Coverage，shapefile和其他格式必须符合10.3文件命名结构（即cxxxxxxxxx.ext，其中“ c”是字母字符，“ x”是字母数字，对于总共13个字符和一个句点，将文件名与扩展名分开）。以下约定应用于生成文件名：ccccccc99c.ext
i。停车代码的4个字符的前缀（请参阅表1）。
ii。5个字符的项目代码，如NCCN项目跟踪数据库中所示。请参阅NCCN跟踪项目信息（NCCN 2005b，正在开发中）。
iii。区分同一项目中GIS图层的单个字符。该单个字符称为GIS项目产品代码，并保存在NCCN项目跟踪数据库中。随着为项目创建或添加更多GIS图层，这应该是按顺序选择的字母字符（即，以a，b，c等开头）。例如，假设该项目已经存在另外两个GIS层，则NOCA Landbird清单项目断面起点的ESRI Arc / Info导出文件的文件名为“ nocabda02c.e00”
。扩展名。ESRI shapefile至少由五个具有相同名称和以下扩展名的文件组成：.shp，.shx，.dbf，.shp，shp.xml和.prj。

对不起，以上段落。
我的经验是，当存在一个不合标准的命名约定时，
1.人们由于难以遵循而将其破坏。
2.人们破坏它以遵守其他标准命名约定。

事实是，有些工具不允许数字的第一个字符文件和字段名，并且RDBMS命名几乎总是遵循这些相同的规则。

印第安那州文档
俄勒冈州文档
Jason Birch文档
Nat Park Serv文档
公共安全多机构文档
河流到达代码似乎忽略了最佳实践
San Antonio文档
更多NPS文档