Iniciar nomes com números é uma convenção de nomenclatura incorreta?

Minha empresa usa o ArcGIS e possui um projeto e padrões de nomeação de arquivos de dados em vigor e (na maior parte) seguidos. Algo que sempre me incomodou com o fato de ele nomear padrões é que ele exige o início de todos os nomes de arquivos de projetos e dados com o número do projeto - um número de oito dígitos . Sempre acreditei que nomear arquivos GIS começando com números é uma coisa ruim e tive processos (especialmente com GRIDS) que falharam por causa do nome do arquivo.

Estou procurando alterar os padrões corporativos para eliminar o requisito de número do projeto, no entanto, não consigo encontrar muita documentação sobre por que "números como primeiro caractere" no nome do arquivo é uma coisa ruim.

Alguém pode me indicar a direção certa, tanto quanto os recursos para apoiar esse argumento?

Esta convenção está apenas implorando para trazer erros de intérpretes de comando incorretos . (É muito fácil confundir dígitos iniciais com um número.)

O sucesso do seu software hoje em evitar esses erros não garante que eles não apareçam em versões futuras. Isso aconteceu várias vezes, ao longo de décadas, com o software GIS da ESRI. Esse comportamento foi amplamente relatado e amplamente documentado. Você não precisa procurar mais do que os próprios fóruns de usuários da ESRI, que datam de uma década. (Pesquisas mais profundas de arquivos antigos de servidores de listas o levarão de volta ainda mais cedo, por volta de 1995.) As pesquisas interessantes do Google incluem

Site "GRD ERROR": forums.esri.com

nome do arquivo 8.3 site: forums.esri.com

Juntos, eles fornecerão cerca de cem exemplos reais dos problemas que esses nomes de arquivos causaram e podem causar novamente.

Evite números se puder -

A Earth Sciences tem um bom exemplo http://library.oceanteacher.org/OTMediawiki/index.php/General_File-Naming_Convention_for_Earth_Science_Datasets#Filename_Sections_in_the_Order_They_Should_Appear

Os espaços podem fazer com que você viaje até - alguns comandos antigos baseados em DOS para mover arquivos quebram se houver espaço envolvido - use "_" (sublinhados) é uma idéia inteligente - isso remonta à estação de trabalho ArcInfo - apenas 8,3 (8 caracteres e formato de arquivo) . Hoje em dia você pode ter mais - mas torná-lo legível para entrega. evitar datas (a maioria dos arquivos tem timestamp)

* Basicamente, siga esta declaração. Exemplo:

As regras de convenção de nomenclatura, conforme direcionado pelo mecanismo Microsoft JET, que permite que aplicativos do Windows como o ArcMap leiam vários formatos de tabela, incluem o seguinte:

• O nome deve começar com uma letra, não um número.
• O nome não deve conter espaços.
• O único caractere especial permitido é um sublinhado.

ArcMap

Qualquer caixa de diálogo de arquivo "Abrir" ou "Selecionar" fará a classificação, assumindo que os arquivos sejam nomeados usando letras. Portanto, se você estiver usando um número exclusivo de oito (!) Dígitos para cada classificação de arquivo de projeto, rapidamente se tornará ilógico. Por exemplo

1
10
2
20
3 etc. 

Além disso, haverá muitas ferramentas GIS que ainda assumirão arquivos que estão em conformidade com o formato de nome de arquivo do MS DOS 8.3 .

Usar os próprios nomes de arquivo como chave para um projeto parece um requisito complicado, na melhor das hipóteses. Seria muito melhor armazenar todos os arquivos em algum tipo de controle de versão nos repositórios de projetos relevantes.

Parece haver uma ausência de restrição na primeira letra numérica como convenção, exceto aqui na convenção NPS.

Nomes de arquivos e tabelas de atributos
A. Produtos finais GIS - As coberturas, os shapefiles e outros formatos devem estar em conformidade com a estrutura de nomes de arquivos 10.3 (ou seja, cxxxxxxxxx.ext, em que "c" é um caractere alfa e "x" é alfanumérico, por um total de 13 caracteres e um período separando o nome do arquivo da extensão). As convenções a seguir devem ser usadas para gerar nomes de arquivos: ccccccc99c.ext
i. Um prefixo de 4 caracteres para o código do parque (consulte a Tabela 1).
ii. Um código de projeto de 5 caracteres, conforme indicado no banco de dados de rastreamento de projetos da NCCN. Consulte as Informações sobre o projeto de rastreamento da NCCN (NCCN 2005b, em desenvolvimento).
iii. Um único caractere que diferencia as camadas GIS dentro do mesmo projeto. Esse caractere único é referido como o código do produto do projeto GIS e é mantido no banco de dados de rastreamento do projeto NCCN. Esse deve ser um caractere alfa selecionado em sequência (ou seja, comece com a, b, c, etc.), à medida que mais camadas GIS são criadas para ou adicionadas ao projeto. Por exemplo, supondo que já existam duas outras camadas de GIS para este projeto, um arquivo de exportação ESRI Arc / Info do ponto de partida da transação do projeto NOCA Landbird Inventory teria um nome de arquivo "nocabda02c.e00"
. Iv. A extensão. Um shapefile de ESRI consistiria em no mínimo cinco arquivos com o mesmo nome e as seguintes extensões: .shp, .shx, .dbf, .shp, shp.xml e .prj. <<

Desculpe pelo parágrafo acima.
Minha experiência foi que, quando há uma convenção de nomenclatura abaixo do padrão,
1. as pessoas a quebram devido à dificuldade de aderência.
2. as pessoas quebram para aderir a outras convenções de nomenclatura padrão.

O fato é que existem ferramentas que não permitem arquivos numéricos de primeiro caractere e nomes de campos, e a nomeação de RDBMS quase sempre segue essas mesmas regras.

Documentação de Indiana Documentação de
Oregon Documentação de
Jason Birch Documentação de
Nat Park Serv Documentação de
várias agências de segurança pública Os
códigos de alcance do rio parecem ignorar as melhores práticas
Documentação de San Antonio
Mais documentação do NPS