É uma boa ideia usar pontos duplos ou sinais de menos duplos como delimitadores? Estou tentando encontrar uma boa convenção de nomenclatura para dados científicos experimentais. Por exemplo:
2017-12-11T19-45..JDoe-042..UO2(NO3)2-EtOAc_dist..150.3K..1.234mM.dat
2017-12-11T19-45--JDoe-042--UO2(NO3)2-EtOAc_dist--150.3K--1.234mM.dat
Meus motivos:
- Para garantir a compatibilidade entre plataformas, os únicos personagens adequados são
_
-
.
e suas combinações; - Nenhum deles pode ser usado sozinho no meu caso :
_
é reservado para os espaços; devido a fórmulas químicas que diferenciam maiúsculas de minúsculas, não posso usar camelCase.-
geralmente faz parte dos códigos internos do laboratório, além de ser usado como um substituto para dois pontos:
no tempo (notação ISO 8601 modificada) e proporções;.
é uma marca decimal.
- Entre suas combinações, a mais popular, ao que parece , é
_-_
. No entanto, são 3 caracteres e os nomes dos arquivos já são bastante longos (como se pode ver nos exemplos), então gostaria de ficar com dois caracteres, se possível. - Visualmente, acho difícil dizer rapidamente a diferença entre
__
e_
, enquanto--
vs-
e.
vs..
são bastante distinguíveis para mim. - Não incluí vírgula
,
(como foi sugerido com razão nos comentários, este também é um caractere viável a ser considerado), pois acho fácil confundi-lo com um único ponto.
, que já está reservado principalmente para os valores numéricos com um ponto decimal.
De acordo com várias postagens na rede SE, por exemplo
- Pontos (“.”) são caracteres válidos em nomes de arquivos ou pastas?
- É uma prática ruim que o nome da pasta contenha ponto (.)? Que tal o nome do arquivo com vários pontos?
- Os nomes dos arquivos devem conter vários pontos?
Eu assumiria ambos --
e ..
são totalmente aceitáveis, e estou pensando em finalmente escolher ..
. No entanto, não tenho certeza, especialmente em relação a como expressões regulares ou scripts python podem lidar com esses arquivos e pastas (tenho muito pouca experiência com ambos, mas estou aprendendo).
Desconsiderando o comportamento de software especializado, você diria que esses delimitadores são geralmente seguros para sistemas de arquivos comuns e linguagens de script?
Uma das decisões de design mais examinadas e questionadas no Unix/Linux é um recurso do sistema de arquivos que está trabalhando a seu favor: qualquer caractere é permitido em um nome de arquivo/diretório, exceto NUL
\0
(ASCII 000) e barra/
(o último sendo reservado para caminhos de arquivo ).Programas e scripts compatíveis com POSIX e/ou bem escritos lidarão com essa indulgência, mas, infelizmente, existem inúmeros exemplos por aí que não o fazem. No entanto, eles tendem a vomitar em um conjunto muito particular de caracteres e esses caracteres não são pontos ou traços. (Espaços e novas linhas são dois dos mais problemáticos.) Na verdade, pontos e traços são amplamente usados. Ferramentas comuns, linguagens e expressões regulares irão lidar com eles bem...
... com uma pequena exceção. (Claro, certo?) Não vejo nenhuma indicação de que você planeja fazer isso, mas deve ser observado: evite travessões no início de um nome. Isso é legal, é claro, mas existem muitos programas que manipularão esses nomes de maneira inadequada, resultando na interpretação deles como opções/sinalizadores de linha de comando. Por exemplo, se um script passar o nome do arquivo para outro script como este:
some-script --my-dash-first-file ...
então não se surpreenda ao ver algo comoUnknown option '--my-dash-first-file'
.TL;DR Seus esquemas propostos são seguros se você evitar nomes que começam com hífen.
Aviso adicional: embora os pontos sozinhos sejam comuns, especialmente para separar o nome base de um arquivo de sua "extensão" (por exemplo
foo.txt
, ), os pontos em pares geralmente são vistos sozinhos... onde eles têm um significado especial: o diretório pai do diretório atual diretório (..
) ou o diretório anterior em um caminho (/foo/bar/../baz
). Portanto, embora isso não cause nenhum problema técnico, os pontos duplos em um nome são um pouco não convencionais e podem fazer com que alguns usuários pensem duas vezes.