Считается ли лучшей практикой не использовать заглавные буквы в именовании файлов?

28

Люди говорят, что вы не должны использовать пробелы в именах файлов Unix. Есть ли веские причины не использовать заглавные буквы в именах файлов (т. File_Name.txtЕ. Против file_name.txt)? Или это просто вопрос личных предпочтений?

filenames DD343
источник
Вы можете использовать заглавные буквы, но как стандарт не используйте это. Просто используйте маленькие буквы и _, так что file_name.txt это хорошо.
Шабир А.
9
Есть некоторые вещи Unixy, которые используют имена файлов с заглавными буквами ... некоторые примеры включают Makefile, INSTALL, CHANGELOG и, конечно, почтенный README.
Томас
PSR-2 - де-факто стандарт именования в мире PHP, который в большинстве своем работает в Linux, использует camelCase php-fig.org/psr/psr-2
jdog

Ответы:

46

Люди говорят, что в именах файлов Unix не должно быть пробелов.

Люди много чего говорят. Есть некоторые инструменты, которые могут испортить, но, надеюсь, их на данный момент мало, потому что места - это вирус, распространяемый гигантскими частными корпорациями, занимающимися запатентованными ОС, и теперь его невозможно избежать.

Пробелы затрудняют указание имен файлов в командной строке и т. Д. Вот и все. Единственные категорически запрещенные символы в системах * nix - это NUL (не волнуйтесь, это не на вашей клавиатуре или чьей-либо еще), и /, поскольку это разделитель пути. +1 Кроме этого ничего не выходит. Отдельные элементы пути (имена файлов) ограничены 255 байтами (возможное осложнение, если вы используете расширенные наборы символов) и полными путями до 4 КиБ.

Или это просто вопрос личных предпочтений

Я бы сказал, что это так. Большинство DE, кажется, создать убивание капитализированных каталогов в вашем $HOME( Downloads, Desktop, Documents- Dочень популярен), так что нет ничего странно об этом. Есть также очень распространенные традиционные файлы с заглавными буквами, такие как .Xclientsи .Xauthority.

Значение заглавных букв в начале состоит в том, что при лексикографическом перечислении они будут предшествовать строчным буквам - по крайней мере, с множеством инструментов и в зависимости от языка.

Я фанат дела о верблюдах (он же camelCase) и использую его с именами файлов, например, /home/goldilocks/blueSuedeShoes- неважно, что там. Определенно, это вопрос личных предпочтений, но он еще не принес мне горя.

Файлы классов Java, как правило, содержат заглавные буквы, потому что имена классов Java это делают. И, конечно, давайте не будем забывать NetworkManager, даже если некоторые из нас предпочтут.

1. Существует гораздо более ограниченный, рекомендованный POSIX «Переносимый набор символов имени файла» , который не содержит пробела, но включает верхний регистр! POSIX также определяет более общее ограничение в отношении «символа косой черты и нулевого байта» в другом месте того же документа . Это отражает или отражается в давних традициях .

лютик золотистый
источник
5
Миа: "Это факт?" Винсент: «Нет, это не так, это только то, что я слышал». Миа: "Кто тебе это сказал?" Винсент: «Они». Миа: "Они много говорят, не так ли?" Винсент: «Они, конечно, делают».
CorsiKa
4
« Значение из спекулируя что - то в самом начале, что когда перечисленный лексический [...], они придут прежде , чем все остальное.» - Конечно, это работает только тогда , когда большинство из имен файлов в нижнем регистре, что дает вам повод для резервных колпачков ( по крайней мере, ведущие заглавные буквы) для ваших READMEс и Makefileс и так далее.
Blacklight Shining
4
На многих клавиатурах ctrl-space или ctrl- @ или alt-0 вводят NUL.
Dubiousjim
2
@dodgethesteamroller Полагаю, вы совершенно ошиблись по поводу прямой косой черты (или, точнее, байта со значением 0x2F) в ext *. На самом деле, я не верю, что он попадет даже в файловую систему; слой VFS запретит его независимо от резервного хранилища.
Звол
3
просто не используйте пробелы в именах файлов и каталогов. даже если ваша система технически это позволяет, это только вызовет у вас горе. Вместо этого используйте «_» символ подчеркивания.
SnakeDoc
9

Одна из причин избегать использования заглавных букв в именах файлов заключается в том, что порядок сортировки в Unix чувствителен к регистру, поэтому файлы, начинающиеся с заглавной буквы, будут отображаться не по порядку. По этой причине Makefileимя обычно пишется с заглавной буквы M- это один из файлов, который вы хотите увидеть первым, без прокрутки / пропуска a-l.

Тем не менее, вы можете сделать гораздо хуже с точки зрения имен файлов:

  • использование пробелов сломает некоторые плохо написанные программы и скрипты, которые неправильно цитируют имена файлов
  • запуск имени файла с помощью -может вызвать проблемы, так как многие программы увидят его как параметр командной строки вместо имени файла (например rm -r, не удалит файл с именем -r).
  • если имя файла .будет начинаться с символа, то оно будет скрыто от многих утилит и оболочки (например rm *, файлы не будут удалены .config)
  • использование специальных символов, таких как |<>*?и даже непечатных символов, newlineтехнически возможно, но может нарушать работу сценариев / программ, аналогичных пробелу. Разница в том, что символ пробела часто используется, поэтому программисты, как правило, проверяют свои программы на него, в то время как менее популярные символы часто остаются непроверенными.
Дмитрий Григорьев
источник
4
Это перестает быть правдой, сортировка в современных локалях в настоящее время не чувствительна к регистру, и многие инструменты и глобальные символы оболочки используют локали для сортировки имен файлов.
Стефан Шазелас
2
Вы хотели сказать: rm *не удалит файлы, как .config?
Wildcard
1
@ Вильдкар не совсем, но, возможно, ваш пример более реалистичен, чем мой. Моя цель состояла в том, чтобы показать, что имена файлов, начинающиеся с точки, не подвержены глобализации, даже если пользователь указывает эту точку явно.
Дмитрий Григорьев
1
@DmitryGrigoryev, нет, это не так. Попробуйте ls -ald. ?? * в любом каталоге, в котором есть точечные файлы.
Билл Барт
1
Я считаю, что было бы более уместно сказать: «Если вы решите использовать заглавные буквы в именах файлов, вы должны иметь в виду тот факт, что порядок сортировки в Unix (иногда) чувствителен к регистру». Пользователь может хотеть этого поведения, Makefileи READMEявляются прекрасными примерами этого. Также обратите внимание, что этот эффект незначителен, если буква не является первой буквой в имени, поэтому это не имеет большого значения, если вы используете camelCase. Конечно, вы можете быть удивлены, увидев anOctagonраньше angle, но, по крайней мере, они будут вместе в списке.
G-Man говорит: «Восстановите Монику»
6

Если вы собираетесь взаимодействовать со средой Windows, вам следует избегать заглавных букв, потому что Windows будет все в нижнем регистре. Это чаще проблема, идущая в другую сторону; ссылка на Page_2.htmlнайдет page_2.htmlв Windows, но не удастся в Unix.

NL_Derek
источник
10
Это не правда. NTFS, VFAT и exFAT не чувствительны к регистру, но сохраняют регистр, то есть они игнорируют регистр в целях поиска, но сохраняют регистр. То же самое относится к HFS +, файловой системе по умолчанию в OSX. NTFS даже имеет пространство имен POSIX, которое работает точно так же, как и все другие Unices, то есть очень длинные имена неинтерпретированных октетов, причем только NULи /запрещено.
Йорг Миттаг
5
Более того, «нечувствительный к регистру, но сохраняющий регистр» - это еще один способ сказать «способный перезаписывать файл A без вывода сообщений, потому что его имя отличается только в случае от файла B» (или наоборот, в зависимости от того, что было сохранено позже). Другими словами, если вы используете оболочку * nix для доступа к общему ресурсу NTFS, cat > Fooфайл будет перезаписан foo. Такое поведение может быть неожиданными и запутанным , если вы привыкли дело , сохраняющие и чувствительны к регистру файловых систем , такие как доб *.
dodgethesteamroller
1
@ JörgWMittag Если я не ошибаюсь, NTFS не учитывает регистр, просто Windows работает загадочным образом.
Ктулху
1
@Cthulhu: AFAIK, NTFS имеет четыре разных пространства имен, в которых вы можете создавать имена для файлов. (Однако я не знаю, может ли один файл иметь имя в нескольких пространствах имен.) Пространство имен «DOS» (8.3, без учета регистра), «длинное» пространство имен (без учета регистра, с учетом регистра, UTF-16), специальное пространство имен для «коротких длинных» имен, то есть имен, регистр которых должен быть сохранен, но вписывается в 8.3, и пространство имен POSIX (поток октетов, отличных от \0и /с учетом регистра). По крайней мере, так я это помню. Но я согласен, что это отчасти беспорядок. Есть дополнительные ограничения в…
Йорг W Mittag
1
… Ядро и даже дополнительные ограничения в API (на самом деле, существуют разные API из разных эпох с разными ограничениями), есть ограничения из-за совместимости с DOS и FAT, есть ограничения в интерпретаторе команд, есть ограничения в ( графическая оболочка, и в Explorer есть ограничения. И зачастую невозможно надежно определить, откуда исходит ограничение. Это безумие. Однажды мне удалось создать файл с помощью Проводника , который нельзя было открыть, скопировать, переместить, переименовать или удалить с помощью любого инструмента, который я пробовал. Это в основном осталось на…
Йорг Миттаг
4

Одна из причин, по которой следует избегать заглавных букв, заключается в том, что при bashзаполнении табуляции учитывается регистр (по крайней мере, по умолчанию) - это все равно сбивает меня с толку каждый раз, когда я оказываюсь перед bashконфигурацией по умолчанию. Конечно, существуют и другие популярные оболочки, но это в сочетании с тем фактом, что bashво многих ОС используется оболочка входа по умолчанию, означает, что по умолчанию это часто завершается с учетом регистра. Использование строчных имен файлов упрощает ситуацию.

Блестящий свет
источник
2
echo set completion-ignore-case On >> ~/.inputrcможет помочь немного, по крайней мере, в вашей собственной системе.
wchargin
1
Мне не ясно, в чем смысл этого ответа - если только вы не забудете, как вы «написали» имя файла. Например, если вы создадите файл с именем Fooи последующим типом cat f(Tab), произойдет сбой. Но то же самое происходит, если вы печатаете cat foo, cat Foobarили cat Fu- тот факт, что у вас будут проблемы с доступом к файлу, имя которого вы не помните правильно, на самом деле не имеет ничего общего с автозаполнением.
G-Man говорит «Восстановить Монику»
@ G-Man Touché. Тем не менее, использование строчных имен файлов означает, что вам нужно помнить о них меньше.
Blacklight Shining
3

Так как NL_Derek открыл эту банку с червями, но не сформулировал ее правильно, я скажу следующее:

Можно использовать заглавные буквы, но вы должны избегать создания файлов (в одном каталоге), которые отличаются только регистром , например, File_Name.txt и file_name.txt , потому что

  • Если вы каким-то образом сделаете каталог доступным для системы Windows, он не сможет получить доступ к обоим файлам. Вероятно, он сможет получить доступ только к тому, который появляется первым в каталоге, независимо от того, какое имя вы используете. (За исключением: он может дать вам доступ к ним как FILENA~1.TXTи FILENA~2.TXT - введите, dir /xчтобы увидеть, какое короткое имя (если есть) идет с каким длинным именем.)
  • Если файловая система на самом деле является файловой системой Windows (например, смонтирована из файловой системы exFAT или NTFS с NFS-сервера под управлением Windows), двум именам (вероятно) не будет разрешено сосуществовать. Например, если вы делаете и , вы можете получить один файл, содержащий выходные данные из .cmd1 > foocmd2 > Foocmd2
  • Точно так же, если вы когда-нибудь перенесете файлы в систему Windows, двум именам (вероятно) не будет разрешено сосуществовать. Например, если вы создали архив (например, zip), содержащий два файла, и извлекли его в системе Windows, второй файл, вероятно, перезапишет первый. То же самое, если вы перенесли их в коробку Windows с FTP или чем-то подобным.
G-Man говорит: «Восстанови Монику»
источник
Не только Windows, но и несколько других ОС (VMS, я думаю, CP / M, конечно, другие ...)
Тоби Спейт
3

Помимо технических причин, у меня есть практический аспект к этому. Придерживаясь строчных букв, вы сможете упростить поиск, если только вы не любите использовать grep -i или locate -i. Иногда, даже camelCase может сбить с толку, если нужно использовать строку слов в подобном случае, как в storageNYCDCPrimary. Поэтому я считаю, что лучше придерживаться строчных букв и перетаскивать их подчеркиванием или дефисом для удобства чтения, например storage_nyc_dc_primary.

Прыгающий кролик
источник
snake_case легок для глаз - storageNycDcPrimaryи StorageNycDcPrimaryоба странны для чтения.
go2null
1

Я действительно считаю , что это лучшая практика , чтобы избежать использования капители и пробелы в именах файлов.

Некоторые скажут, что они не согласны, но это вопрос или то, что я называю религиозными убеждениями : трудно обсуждать и соглашаться. Те, кто не согласен, говорят, что большинство инструментов теперь исправлены, чтобы быть дружественными к столицам и пространствам: они правы, но это не вопрос.

Правильный вопрос - сколько вам нужно использовать заглавные буквы и пробелы в именах файлов. На этот вопрос, кроме случаев, когда я занимаюсь программированием на Java, ответ в основном все время: мне не нужны заглавные буквы и пробелы в именах файлов . Все пробелы я заменяю подчеркиванием ( _) или знаком минус ( -), и из-за этого я не использую случай верблюда (он же camelCase) вопреки какой-либо другой религии.

Многие люди называли меня ерундой за то, что я делал и учил этому - некоторые из них все еще делают - некоторые из них споткнулись о инструмент, который не был дружественным по отношению к капиталу и космосу, и пришли ко мне, сказав, что я был прав и что они должны были слушать меня. Делайте что хотите , и если вы используете заглавные буквы и пробелы в имени файла, я надеюсь, что вы никогда не запутаетесь в плохо написанном инструменте. Тем не менее, если вы отключитесь от такого инструмента, надеюсь, вам будет легко его исправить, и он не будет стоить вашему бизнесу и / или вам много денег и / или времени. Но если это в конечном итоге приведет к плохим последствиям, вы помните, что некоторые в прошлом говорили вам, что использование заглавных букв и пробелов в именах файлов - плохая практика.

И последнее: если вы хотите избежать всех проблем , не используйте специальные символы в именах файлов (только строчные буквы, цифры, подчеркивание и минусы [1]). Этот список нежелательных символов также включает в себя все не ascii символы (да, французы и другие неанглийские люди - и я один из них - ни один из них: à, â, ä, ç, é, ..., ö, æ, œ ...). Это также распространяется на многие другие вещи, включая логин и пароль . Я позволю вам угадать, что произойдет, когда вы введете кавычку или двойную кавычку ( 'или ") в логин или пароль, которые обрабатываются скриптом bash, не написанным подтвержденным сисадмином ....

[1]: может быть , мы могли бы расширить , что ~, @, #и некоторые другие, но это ищет неприятности (и да , я знаю о EMACS файлов ...).

jfg956
источник
1
Последнее, что должно обрабатывать система аутентификации, а не пользователь, придумавший пароль. Если система ограничивает набор разрешенных символов в паролях, это плохая система.
Blacklight Shining
Что ж, ограничение символов в пароле является предметом спора: li1, oO0, ... в зависимости от увлечения, трудно общаться. Кто-то скажет, что пароль не следует сообщать, но ключ WiFi - это своего рода пароль, который я
сообщаю
С вашей стороны это сознательный выбор - избегать использования некоторых символов, а не ограничений, встроенных в систему (в этом примере, стандартов Wi-Fi, точек доступа и клиентских реализаций и т. Д.). Если вы используете в качестве пароля строку случайно выбранных символов, вы можете улучшить удобочитаемость, используя (или поощряя получателей использовать) моноширинный шрифт или просто используя более характерные глифы, если вы пишете их от руки (строчные буквы с засечками) L, верхний регистр I и цифра 1; меньший строчный O, верхний регистр O круглого, косая или пунктирная цифра 0 и т. Д.). В качестве альтернативы, вы можете использовать фразу-пароль.
Blacklight Shining