Длинные имена и как с этим бороться?

Ссылка скопирована
Веб-разработка Программирование
2 ответов

Целая куча есть проблем с длинными именами, директориями и национальными названиями.
Сталкиваются наверное все, в виндоуз больше, в линуксе да примерно так же.
Итак решил собрать пакет советов как избежать проблем.
1. C:Userskorotenko-vnМои документыпроектыSomeProject
Тут целых 3 проблемы: Длинные имена с пробелами, кирилица и длина пути, если в списке модулей будет что то больше 260 символов то вас ждет сюрприз

2. C:Userskorotenko-vnМои документыпроектыSomeProject пакуете это все в зип и распаковав в линуксе получаете тыкву в виде win1251 в путях

3. линукс специфичные команды в package.json например "md dist && cp -R ..static && make build" - решается запуском из под bash shell Из git tools или кардинально установкой пакетов для аналогов этих программ

4. Visual studio создает файлы в национальной кодировке, это реально бесит, настраивается в настройках указанием создавать в utf8

5. Питон и многие другие другие просто не переваривают пробелы - лечится указанием Progra~1 вместо Programm Files

Что еще вам встречалось?

Дополнительно:

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

  • В линуксе нет проблем НИ с длинными именами, НИ с кодировками, НИ с закидонами самой системы, пытающейся поддерживать совместимость с легаси 30-летней давности. Аналогично на Маках, Бздях и прочих Юниксах.
    Так что тег "windows" был бы уместен ;)
  • Денис _______________, В линуксе и другие проблемы есть, хотя если честно это даже не проблемы его а прикладных библиотек.
    Например руками правленый зип с вложенными папками и одним файлом на который ссылается эта папка.
    При попытке распаковки создаются рекурсивно папки и этот самый файл на 10 мегабайт в каждой.

    Ну или просто скрипт создающий рекурсивно папки, пока не выберутся все inode

  • Adamos,

    В линуксе нет проблем НИ с длинными именами, НИ с кодировками, НИ с закидонами самой системы, пытающейся поддерживать совместимость с легаси 30-летней давности. Аналогично на Маках, Бздях и прочих Юниксах.
    Так что тег "windows" был бы уместен ;)

    Упомянутые мной пробелы не проблема? Мне вспоминается один известный вендор дров который из за пробела стирал "/"
    Как то я получал эксель в koi8r, это был цирк. Ну а в другой раз опен офис формировал эксель в utf8 виндовый же офис выдавал кракозяблы, пришлось перекодировать в 1251.
    Насчет Unix не скажу ничего, система развивается 60 лет? ожидаемо что косяков не будет а линукс в каком году появился? 91?

  • Владимир Коротенко, так Линукс не изобретал собственные велосипеды, а реализовал стандарты того же Юникса.
    Пробелы - не проблема: если вы набираете команду в терминале, автодополнение подставит экранирующие слеши, а если пишете скрипт - так любой грамотный человек берет пути в кавычки, это базовые знания при скриптописании, и то, что у известного вендора работали подоконники, не владеющие вопросом, и под линь писали на отвяжись и как умели - это проблема отнюдь не Линукса.
    Зипа это тем более касается - вот уж что давно просится на свалку, кабы не распространенность - 7z его кроет, как бык овцу и не создает проблем ни под какими системами.

    • Ответы:

    А причём здесь web-разработка?

    Вы о говорите о различных инструментах, типа npm composer и т.п.?

    Тут всё просто. Во-первых, профиль в винде необходимо переименовать, если он кириллический.
    Во-вторых, забываем про все виртуальные виндовые папки, тип Рабочий стол, Мои документы и т.п. Лучше покупаем отдельный диск для разработки. Ну можно и "С" использовать конечно =), однако, я никогда не храню данные на системном диске. Привычка с лохматых времен, когда винда падала чуть ли не ежемесячно. D:dev, или С:dev, и никаких проблем.
    Вспомогательные инструменты ставим в корень диска

    c:composer c:git c:nodejs c:python2

    c:composer c:git c:nodejs c:python2

    Не забываем поправить системный PATH, если нужно.

    • Веб-разработка здесь таким боком. На Тостере часто спрашивают, стоит ли переходить на Линукс для веб-разработки или нужна винда. Этот "вопрос" частично отвечает на этот вопрос ;)
    • Adamos, Linux может и хорош для web dev, но для заядлого виндузятника переход будет сильным стрессом. в окошках с правильным подходом тоже неплохо разрабатывается.
    • Сергей delphinpro, борьба с застойными явлениями тем болезненнее, чем более они запущены.
      Это весьма универсальное правило, и к синдрому утенка оно тоже относится.
    • Adamos, Но согласись экранировать строки с пробелами нужно и там и там. В виндоуз еще и может добавится то что программа не понимает путь из 9 и более символов, что тоже добавляет лулзов
    • Сергей delphinpro

      А причём здесь web-разработка?

      В веб разработке часто используются утилиты на виндоуз из линукса которые не любят виндоуз, ну или не понимают

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

      Длинные имена и как с этим бороться?

    • Сергей delphinpro, Решение, но я проще делаю d:projects
    • Винда сама всегда делает папку с транслитерированым именем профиля, ну или его частью если оно длинное
    • imko, винда затыкает пути костылями симлинков для совместимости, что, на самом деле, не столько решает проблему, сколько создает: программа может быть запущена так, что видит симлинкованный путь, который забыли предусмотреть при тестировании.
    Нужно решить такую задачу?

    Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.

    Заказать помощь
    Лучший ответ
    1
    Анна SEO Ответ

    Длинные имена переменных, функций и классов могут затруднять чтение кода и увеличивать вероятность ошибок при разработке. Однако, хорошо подобранные имена могут значительно улучшить читаемость и понимание кода другими разработчиками. Вот несколько советов, как бороться с этой проблемой:

    1. Используйте описательные и понятные имена: Названия переменных, функций и классов должны четко отражать их назначение. Избегайте слишком общих или абстрактных названий, таких как "data" или "value". Лучше использовать более конкретные имена, которые легко понять при первом прочтении кода.

    2. Избегайте слишком длинных имен: Хотя длинные имена могут быть более описательными, они также могут усложнять чтение кода. Постарайтесь найти баланс между длиной и понятностью названия. Если имя становится слишком длинным, это может быть признаком того, что код нуждается в рефакторинге.

    3. Используйте соглашения по именованию: Следуйте установленным соглашениям по именованию в выбранном языке программирования. Например, в PHP можно использовать CamelCase для имен переменных и функций, а для классов - StudlyCaps. Это поможет сделать код более последовательным и удобным для чтения.

    Пример использования хороших имен переменных в PHP:

    $userName = "JohnDoe";
$userAge = 30;
 
function greetUser($name, $age) {
    echo "Hello, $name! You are $age years old.";
}
 
greetUser($userName, $userAge);

    $userName = "JohnDoe"; $userAge = 30; function greetUser($name, $age) { echo "Hello, $name! You are $age years old."; } greetUser($userName, $userAge);

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

    Другие ответы (1) Ответить на вопрос
    Анна SEO

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

    1. Используйте осмысленные имена: старайтесь выбирать имена, которые ясно отражают суть переменной, функции или класса. Это поможет другим разработчикам и вам самим легче понимать код.

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

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

    4. Разделяйте слова знаками подчеркивания или верхним регистром: для улучшения читаемости кода можно разделять слова в именах переменных и функций знаками подчеркивания (_) или использовать верхний регистр (CamelCase).

    Пример использования верхнего регистра (CamelCase) в PHP:

    $myVariableName = "Value";
function myFunctionName() {
  // some code here
}
class MyClass {
  // class code here
}

    $myVariableName = "Value"; function myFunctionName() { // some code here } class MyClass { // class code here }

    Пример использования знака подчеркивания в PHP:

    $my_variable_name = "Value";
function my_function_name() {
  // some code here
}
class My_Class {
  // class code here
}

    $my_variable_name = "Value"; function my_function_name() { // some code here } class My_Class { // class code here }

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

    комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *

    Вам также может быть интересно

    VPN Как правильно настроить vless для Android TV? 1 ответ Pyrogram Как правильно зарегистрировать юзер бота в Telegram? 1 ответ печатные-платы Как заставить запускаться программу M3.exe от компании Hanxing AOI в инспекционной машине на Windows 7 Pro? 1 ответ SMM Из-за чего не сохраняется видео в мобильной программе blackmagic? 1 ответ