Использование подчеркивания в именах файлов?

Я часто использую командную строку для навигации по своим файлам, поэтому стараюсь не использовать пробелы в названиях файлов. Обычно я использую подчеркивание для соединения слов, но недавно мне посоветовали использовать дефис. Есть ли какие-либо недостатки в использовании подчеркивания в названиях файлов? Стоит ли мне перейти на дефис? Моя система работает на Xubuntu, и я почти исключительно использую оболочку bash.

Спасибо

Что касается операционной системы, то оба варианта одинаково удобны.

Одно, что я бы отметил – некоторое программное обеспечение (например, некоторые видеопроигрыватели – XBMC и т.д.) автоматически заменяет подчеркивания на пробелы при отображении файлов, чтобы сделать их более эстетичными.

По этой причине я бы предпочел оставить подчеркивания.

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

Кроме этого, это вопрос личного выбора.

Дефисы не требуют нажатия клавиши SHIFT, что позволяет набирать текст быстрее. Это единственное другое преимущество, о котором я могу подумать, кроме того, что предложил мистер Дженкинс.

Вероятно, человек, который сделал это предложение, является заядлым пользователем Vim и хочет сделать все с минимальным количеством движений клавиатуры.

Моя рекомендация – использовать подчеркивания вместо пробелов. Подчеркивания обычно являются общепринятой практикой, которую люди используют, заменяя пробелы, хотя я бы сказал, что дефисы тоже неплохие. Но поскольку дефисы могут появляться и в других контекстах, таких как сложные слова, вы будете успешнее сохранять смысл имени, используя подчеркивания. Например, если у вас есть файл с именем “A picture taken in Winston-Salem, NC.jpg” и вы хотите заменить пробелы на подчеркивания, вы сможете сохранить дефис и сохранить его значение.

Пробелы создают проблемы для людей, которые хотят использовать командную строку более сложными способами, такими как в циклах for:

for file in *.mp3 ; do mpg321 $file -w - | oggenc -o ${file%%.mp3}.ogg - ; done

Если любое из mp3-файлов, соответствующих этому шаблону, содержит пробелы в своем имени, это приведет к тому, что имя файла будет разбито на части, а не будет восприниматься целиком. Вы можете обойти это, изменив переменную IFS оболочки BASH или используя команду find, но это раздражает, и многие люди этого не знают, поэтому это может вызвать проблемы.

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

Единственная причина, по которой вы должны рассмотреть возможность использования дефисов вместо подчеркиваний, – это базовая читаемость. Частые подчеркивания имеют тенденцию искажать чтение, поскольку они изменяют линию вашего зрения с центра вертикальной оси на низ. Дефисы, однако, облегчают восприятие.

Что касается операционной системы, то оба символа одинаково допустимы и не требуют экранирования (в отличие от пробелов, что затрудняет работу с ними).

Лично я предпочитаю дефисы подчеркиванию, потому что для них не нужно удерживать клавишу shift. Но одна вещь, которую стоит помнить, это то, что если вы в основном пишете код на Python – и ваше дерево кода содержит файлы/каталоги с дефисами, и вы намерены использовать их в качестве модулей (импортировать имя файла в коде), то это приведет к ошибкам, так как модули Python не могут содержать дефисы. Конечно, есть обходные пути для импорта модулей, содержащих дефисы, но я бы придерживался подчеркивания, так как это также соответствует рекомендациям PEP-8.

Таким образом, для большинства моих bin/ программ или псевдонимов я использую дефисы, но когда дело доходит до написания программ/модулей на Python – я использую подчеркивания.

Существуют веские причины использовать дефисы в любом контексте, связанном с вебом, который сопоставляется с файловой системой Unix.

URL               Что видят поисковые индексы
foo-baz-bang      foo baz bang
foo_baz_bang      foobazbang

Как веб-разработчик, это заставило меня придерживаться дефисов при разделении слов.

Я не видел этого упомянутым, но много программного обеспечения в наши дни не считает подчеркивание разделителем слов (тоже называется “разделяющим символом”). Другими словами, вы не можете перейти к следующему слову с помощью Ctrl+Right-arrow или выделить отдельные слова двойным щелчком по ним.

Аргумент заключается в том, что имена переменных в некоторых языках программирования, таких как Python, используют snake_case, поэтому выделение их может потребовать дополнительного Ctrl+Right-arrow.

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

По этой причине я предлагаю не повторять мою ошибку и вместо этого выбрать дефис.

Подчеркивания являются заменой пробелов в ситуациях, когда пробелы не могут быть использованы; глаз обычно пропускает их и игнорирует их присутствие.

You_can_write_whole_sentences_using_underscores, и это будет выглядеть немного так, как будто они были подчеркиваны, но в остальном это вполне читаемо, на мой взгляд.

Дефисы используются для соединения слов, таких как “блендер для яиц”, который теперь рассматривается как одно слово, хотя и состоит из двух слов. Но иногда эти составные слова становятся настолько привычными, что дефис теряется, и сегодня вполне нормально писать “блендер для яиц”.

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

Одна из проблем с подчеркиванием заключается в том, что множество программного обеспечения не знает, как разбивать их по строкам. Общепринято считать, что вы можете разбивать составные слова по дефису, но много программного обеспечения обрабатывает подчеркивание как буквенный знак и будет разбивать произвольно, что часто выглядит неаккуратно. Например:

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

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

И чтобы прояснить, – на клавиатуре – это на самом деле дефис-минус. Это не тире, и это не совсем дефис или минус.

На печатных машинках был только дефис, который также можно было использовать как знак минус, но также I (заглавная i) и O (заглавная o) также использовались для 1 (один) и 0 (ноль), потому что ранние пишущие машинки этих цифр тоже не имели. А чтобы написать +, вам нужно было ввести -, затем вернуться и написать ; поверх него. – был добавлен на пишущие машинки для ввода дефисов, чтобы соединять слова или разбивать слово на две строки (что сейчас делается редко). Последнее также показывает, что дефис предназначен для “соединения вещей”.

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

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

• дефис-минус: – (это то, что вы печатаете, U+002D)
• минус: − (настоящий минус, но редко выглядит иначе, если + выглядит иначе, в этом случае он будет совпадать с этим видом, U+2212)
• дефис: ‐ (должен быть короче минуса, также может иметь различное вертикальное выравнивание в зависимости от шрифта, U+2010)
• короткое тире: – (также известен как en dash, может быть немного длиннее минуса, должен иметь то же вертикальное выравнивание, что и дефис, U+2013).
• длинное тире: — (также известен как em dash, должен быть длиннее короткого тире, обычно в два раза длиннее, U+2014)