É considerado uma boa prática não usar letras maiúsculas na nomenclatura de arquivos?

Question

As pessoas dizem que você não deve usar espaços na nomeação de arquivos do Unix. Há boas razões para não usar letras maiúsculas nos nomes dos arquivos (por exemplo, File_Name.txt vs. file_name.txt )? Ou isso é apenas uma questão de preferência pessoal?

    

Answer 1

People say you shouldn't spaces in Unix file naming.

As pessoas dizem muitas coisas. Existem algumas ferramentas que podem estragar, mas esperamos que sejam poucas em número neste momento, uma vez que os espaços são um vírus proliferado por corporações de sistemas operacionais de propriedade do consumidor gigantes e agora é impossível evitar.

Os espaços tornam a especificação de nomes de arquivos na linha de comando, etc., desajeitada. É sobre isso. Os únicos caracteres categoricamente proibidos nos sistemas * nix são NUL (não se preocupe, não está no seu teclado nem em qualquer outra pessoa) e / , já que esse é o separador de caminho. ¹ qualquer coisa serve. Elementos de caminho individuais (nomes de arquivos) são limitados a 255 bytes (uma possível complicação se você estiver usando conjuntos de caracteres estendidos) e caminhos completos para 4 KiB.

Or is this just a matter of personal preference

Eu diria que é. A maioria dos DEs parece criar uma enorme quantidade de diretórios em letras maiúsculas no seu $HOME ( Downloads , Desktop , Documents - o D é muito popular), então não há nada de bizarro nisso. Também existem arquivos tradicionais comuns com maiúsculas, como .Xclients e .Xauthority .

Um valor de capitalizar as coisas no início é que, quando listadas de forma lexicográfica, elas aparecerão antes de minúsculas - pelo menos, com muitas ferramentas e sujeitas à localidade.

Sou fã de camel case (também conhecido como camelCase) e uso-o com nomes de arquivos, por exemplo, /home/goldilocks/blueSuedeShoes - não importa o que está lá. Definitivamente uma questão de preferência pessoal, mas ainda não me causou sofrimento.

Os arquivos de classe Java tendem a conter maiúsculas por natureza, porque os nomes de classes Java. E, claro, não vamos esquecer NetworkManager , mesmo que alguns de nós prefiram.

^{1. Há um muito mais delimitado, recomendado por POSIX "Conjunto de caracteres de nome de arquivo portátil" < em> doesn't inclui o espaço - mas inclui letras maiúsculas! POSIX também especifica a restrição mais geral referente a "o caractere de barra e o byte nulo" esobre o mesmo documento . Isso reflete, ou é refletido em, práticas convencionais de longa data .}

    

Answer 2

Se você for interagir com um ambiente Windows, você deve evitar maiúsculas porque o Windows reduzirá tudo. Isto é mais frequentemente um problema indo para o outro lado; um link para Page_2.html encontrará page_2.html no Windows, mas falhará no Unix.

    

Answer 3

Um motivo para evitar limites em nomes de arquivos é que a ordem de classificação no Unix faz distinção entre maiúsculas e minúsculas, portanto, os arquivos que começam com uma letra maiúscula serão exibidos fora de ordem. Essa é a razão pela qual Makefile é geralmente nomeado usando um% maiM - é um dos arquivos que você deseja ver primeiro, sem rolar / percorrer a-l .

Dito isto, você pode fazer muito pior em termos de nomes de arquivos:

• usando espaços irá quebrar alguns programas e scripts mal escritos que não citam nomes de arquivos corretamente
• iniciar um nome de arquivo com - pode causar problemas, pois muitos programas o verão como uma opção de linha de comando em vez de um nome de arquivo (por exemplo, rm -r não removerá um arquivo chamado -r ).
• iniciar um nome de arquivo com . ocultá-lo de muitos utilitários e globalização de shell (por exemplo, rm * não removerá arquivos como .config )
• usando caracteres especiais como |<>*? e até caracteres não imprimíveis como newline são tecnicamente possíveis, mas podem quebrar scripts / programas semelhantes ao caractere de espaço. A diferença é que o caractere de espaço é usado com frequência, portanto, os programadores tendem a testar seus programas com relação a ele, enquanto os caracteres menos populares geralmente não são testados.

Answer 4

Um motivo para evitar limites é que bash s conclusão da tabulação diferencia maiúsculas de minúsculas (pelo menos por padrão) - isso ainda me atrapalha toda vez que eu acabo na frente de um bash com configuração padrão. Claro, existem outros shells populares, mas isso combinado com o fato de que bash é o shell de login padrão em muitos sistemas operacionais significa que o padrão é, muitas vezes, a conclusão com distinção entre maiúsculas e minúsculas. Usar nomes de arquivos com todas as letras minúsculas simplifica as coisas aqui.

    

Answer 5

Desde que o NL_Derek abriu esta lata de worms, mas não a articulou corretamente, Eu vou dizer isso:

Não há problema em usar letras maiúsculas, mas você deve evitar a criação de arquivos (no mesmo diretório) que diferem somente por caso , por exemplo, File_Name.txt e file_name.txt , porque

• Se você de alguma forma disponibilizar o diretório para um sistema Windows, ele não poderá acessar os dois arquivos. Ele provavelmente será capaz de acessar somente aquele que aparece primeiro no diretório, independentemente do nome que você usa. (Exceto: pode dar acesso a eles como FILENA~1.TXT e FILENA~2.TXT - digite dir /x para ver qual nome curto (se houver) combina com o nome longo.
• Se o sistema de arquivos for realmente um sistema de arquivos do Windows (por exemplo, montado em um sistema de arquivos exFAT ou NTFS de um servidor NFS executando o Windows), os dois nomes (provavelmente) não poderão coexistir. Por exemplo, se você fizer cmd1 > foo e cmd2 > Foo , você pode acabar com um único arquivo, contendo a saída de cmd2 .
• Da mesma forma, se você transferir os arquivos para um sistema Windows, os dois nomes (provavelmente) não poderão coexistir. Por exemplo, se você criou um arquivo (por exemplo, zip) contendo os dois arquivos, e extraí-lo em um sistema Windows, o segundo arquivo provavelmente substituiria o primeiro. Mesma coisa se você os transferiu para uma caixa do Windows com FTP ou algo semelhante.

Answer 6

Além de razões técnicas, tenho um aspecto prático nisso. Manter as letras minúsculas garantirá que as pesquisas sejam mais fáceis, a menos que alguém goste muito de usar o grep -i ou localize -i. Às vezes, até mesmo o camelCase pode ser confuso se for necessário usar uma sequência de palavras semelhantes como no storageNYCDCPrimary. Então, acho melhor ficar com letras minúsculas e apimentá-las com sublinhados ou hífens para facilitar a leitura, como por exemplo storage_nyc_dc_primary.

    

Answer 7

Eu considero que é uma prática recomendada evitar o uso de maiúsculas e espaços em nomes de arquivos.

Alguns dirão que não concordam, mas é uma questão ou o que eu chamo de crenças religiosas : difícil de discutir e concordar. Aqueles que não concordam dizem que a maioria das ferramentas agora está fixada para ter capital e espaços amigáveis: eles estão certos, mas essa não é a questão.

A pergunta certa é quanto você precisa usar maiúsculas e espaços em nomes de arquivos. Para esta pergunta, exceto quando estou programando em Java, a resposta é principalmente o tempo todo: Eu não preciso de capitais e espaços em meus nomes de arquivos . Todos os espaços que eu substituo por um sublinhado ( _ ) ou um sinal de menos ( - ), e por causa disso eu não uso o caso camel (aka. CamelCase) ao contrário de algumas outras religiões.

Muitas pessoas me chamaram de besteira por fazer e ensinar isso - algumas ainda fazem - algumas delas tropeçaram em uma ferramenta que não era amigável ao capital / espaço e vieram até mim dizendo que eu estava certo e que deveriam ter escutado para mim. Faça o que quiser , e se você usar maiúsculas e espaços no nome do arquivo, espero que você nunca tropece em uma ferramenta mal escrita. No entanto, se você tropeçar em tal ferramenta, espero que, novamente, não seja difícil consertar e não vai custar seu negócio e / ou muito dinheiro e / ou tempo. Mas se acabar tendo repercussões ruins, você se lembrará de que alguns disseram no passado que usar maiúsculas e espaços em nomes de arquivos é uma prática ruim.

E uma última coisa, se você quiser evitar todos os problemas , nenhum caractere especial em nomes de arquivos (apenas letras minúsculas, dígitos, sublinhados e minus [1]) . Esta lista de caracteres indesejados também inclui todos os caracteres não ascii (sim, franceses e outros não ingleses - e eu sou um deles - nenhum deles: à, â, ä, ç, é, ..., ö, æ, œ ...) Isso também se estende a muitas outras coisas, incluindo login e senha . Eu vou deixar você adivinhar o que acontece quando você coloca uma cotação ou aspas duplas ( ' ou " ) em um login ou senha que é tratado por um script bash não escrito por um administrador de sistema confirmado ....

[1]: talvez pudéssemos estender isso para ~ , @ , # e alguns outros, mas isso está procurando por problemas (e sim, eu sei sobre arquivos emacs ...).