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, PC та Linux щодо змінних середовища та аргументів командного рядка, але я можу сказати вам:
- всі троє мають підтримку змінних середовища
- всі вони підтримують аргументи командного рядка
Так, я знаю - це не дуже допомогло. Вибачте. Але ключовим моментом є те, що ви можете розраховувати на розумне рішення, яке буде портативним, хоча ви точно хочете перевірити це для своїх програм (наприклад, чи чутливі до регістру аргументи командного рядка на будь-яких платформах? На всіх платформах? Я не знаю ).
Останнє:
Як згадував Томаш, для більшості додатків не повинно бути важливо, звідки походять параметри.