Ответ 1
1) Я бы рекомендовал максимально избегать переменных окружения.
Плюсы переменных окружения
- проста в использовании, потому что они видны из любого места. Если множество независимых программ нуждаются в информации, этот подход намного удобнее.
Минусы переменных окружения
- трудно использовать правильно, потому что они видны (удаляемые, настраиваемые) из любого места. Если я установлю новую программу, которая опирается на переменные окружающей среды, они будут топать по моим существующим? Неужели я непреднамеренно испортил свои экологические переменные, когда вчера обедал?
Мое мнение
- используйте аргументы командной строки для тех аргументов, которые, скорее всего, будут отличаться для каждого отдельного вызова программы (т.е. n для программы, которая вычисляет n!)
- используйте конфигурационные файлы для аргументов, которые пользователь может разумно изменить, но не очень часто (например, размер экрана при всплывании окна).
- экономно использовать переменные среды - желательно только для аргументов, которые, как ожидается, не будут меняться (т.е. местоположение интерпретатора Python)
- ваша точка
They are global and accessible from anywhere, which is less elegant from architectural point of view, but limits the amount of codeнапоминает мне об обоснованиях использования глобальных переменных;)
Мои шрамы из-за того, что из первых рук испытывают ужасы перегрузки окружающей среды
- две программы, которые нам нужны на работе, которые не могут работать на одном компьютере одновременно из-за экологических столкновений.
- несколько версий программ с одним и тем же именем, но с разными ошибками - часами целая мастерская стояла на коленях, потому что расположение программы было вытащено из среды и было (тихо, тонко) неправильно.
2) Пределы
Если бы я нажимал пределы того, что может удерживать командная строка, или то, что может обрабатывать среда, я бы немедленно реорганизовал.
Я использовал JSON в прошлом для приложения с командной строкой, которому нужно было много параметров. Было очень удобно использовать словари и списки, а также строки и номера. Приложение заняло всего несколько аргументов командной строки, одним из которых было расположение файла JSON.
Преимущества такого подхода
- не нужно было писать много (болезненный) код для взаимодействия с библиотекой CLI - может быть больно заставить многие из общих библиотек выполнять сложные ограничения ( "сложным" я имею в виду более сложным, чем проверка определенного ключа или чередование между набором клавиш)
- не нужно беспокоиться о требованиях к библиотекам CLI для порядка аргументов - просто используйте объект JSON!
- легко представлять сложные данные (отвечающие
What won't fit into command line parameters?), такие как списки - легко использовать данные из других приложений - как для создания, так и для анализа программно
- легкость размещения будущих расширений
Примечание. Я хочу отличить это от подхода .config-file - это не для сохранения конфигурации пользователя. Может быть, я должен назвать это "параметром командной строки", потому что я использую его для программы, для которой требуется множество значений, которые не подходят в командной строке.
3). Переносимость порта: я не знаю много о различиях между Mac, ПК и Linux в отношении переменных окружения и аргументов командной строки, но могу вам сказать:
- все три имеют поддержку переменных окружения
- все они поддерживают аргументы командной строки
Да, я знаю - это было не очень полезно. Прости. Но ключевым моментом является то, что вы можете ожидать, что разумное решение будет переносимым, хотя вы определенно хотите проверить это для своих программ (например, являются ли аргументы командной строки аргументами с учетом регистра на любых платформах? платформы? Я не знаю).
Последняя точка:
Как отметил Томаш, это не должно иметь большого значения для большинства приложений, из которых были получены параметры.