Is starting names with numbers a bad data naming convention?

Question

My company uses ArcGIS and has a project and data file naming standards in place and (for the most part) followed. Something that has always bothered me about he naming standards is that it mandates starting all project and data file names with the project number - an eight digit number. I've always held the belief that naming GIS files starting with numbers is a bad thing, and have had (especially with GRIDS) processes fail because of the file name.

I'm looking to amend the corporate standards to drop the project number requirement, however I cannot find much in the way of documentation on why "numbers as a first character" in filename is a bad thing.

Can anyone point me in the right direction as far as resources to support this argument?

Answer 1

This convention is just begging to bring out bugs from bad command interpreters. (It is all too easy to confuse initial digits with a number.)

Your software's success today in avoiding such bugs is no guarantee that they won't appear in future releases. This has happened multiple times, over decades, with ESRI's GIS software. This behavior has been extensively reported and amply documented. You need look no further than ESRI's own user forums, which date back a decade. (Deeper searches of old listserver archives will take you back even earlier, to around 1995.) Interesting Google searches include

"GRD ERROR" site:forums.esri.com

filename 8.3 site:forums.esri.com

Together these will provide around a hundred actual examples of the problems such filenames have caused and potentially could cause again.

Answer 2

Avoid Numbers if you can -

Earth Sciences has a good example http://library.oceanteacher.org/OTMediawiki/index.php/General_File-Naming_Convention_for_Earth_Science_Datasets#Filename_Sections_in_the_Order_They_Should_Appear

Spaces can trip you up to - some old DOS based commands for moving files break if space are involved - use "_" (underscores) is a wise think - this stems back to ArcInfo workstation - only 8.3 (8 characters and the file format). These days you can have more - but make it human readable for delivery. avoid dates (most files are timestamped)

*Basically go by this statement Example:

Naming convention rules, as directed by the Microsoft JET engine, which enables Windows applications like ArcMap to read various table formats, include the following:

• The name must start with a letter, not a number.
• The name must not contain spaces.
• The only special character allowed is an underscore.

ArcMap

Answer 3

Any "Open" or "Select" file dialog is going to do sorting assuming the files are named using letters. So if you are using an eight (!) digit unique number for every project file sorting will quickly become illogical. E.g.

1
10
2
20
3 etc. 

Besides there'll be plenty of GIS tools that will still be assuming files that conform to the MS DOS 8.3 filename format.

Using filenames themselves as a key to a project seems a cumbersome requirement at best. It would be far better to store all files in some sort of version control in relevant project repositories.

Answer 4

There seems to be an absence of restriction on first letter numeric as a convention except here in the NPS convention.

File and attribute table names
A. GIS Final Products – Coverages, shapefiles and other formats must conform to a 10.3 file naming structure (that is, cxxxxxxxxx.ext, where “c” is an alpha character and “x” is alphanumeric, for a total of 13 characters and one period separating the filename from the extension). The following conventions should be used to generate file names: ccccccc99c.ext
i. A 4-character prefix for park code (see Table 1).
ii. A 5-character project code, as indicated in the NCCN project tracking database. Refer to NCCN Tracking Project Information (NCCN 2005b, in development).
iii. A single character differentiating GIS layers within the same project. This single character is referred to as the GIS project product code and is maintained in the NCCN project tracking database. This should be an alpha character selected in sequence (i.e., start with a, b, c, etc.) as more GIS layers are created for or are added to the project. For example, assuming that there already exist two other GIS layers for this project, an ESRI Arc/Info export file of the NOCA Landbird Inventory project transect starting points would have a file name of “nocabda02c.e00.”
iv. The extension. An ESRI shapefile would consist of a minimum of five files with the same name and the following extensions: .shp, .shx, .dbf, .shp, shp.xml, and .prj.<<

Sorry for above paragraph.
My experience has been that when there is a substandard naming convention that
1. people break it because of difficulty in adherance.
2. people break it to adhere to other standard naming conventions.

The fact is that there are tools the do not allow numeric first character file and field names, and RDBMS naming almost always follows these same rules.

Indiana documentation
Oregon documentation
Jason Birch documentation
Nat Park Serv documentation
Public Safety Multi-Agency documentation
River reach codes seems to ignore best practices
San Antonio documentation
More NPS documentation