command-line - 参数传递策略 - 环境变量与命令行

Question

我们开发人员编写的大多数应用程序都需要在启动时进行外部参数化。我们传递文件路径、管道名称、TCP/IP 地址等。到目前为止，我一直在使用 命令行 将这些传递给正在启动的应用程序。我必须解析 main 中的命令行并将参数指向需要它们的地方，这当然是一个很好的设计，但是对于大量参数来说很难维护。最近我决定使用 环境变量 机制。它们是全局的，可以从任何地方访问，从架构的角度来看不太优雅，但限制了代码量。

这些是我对这两种策略的第一印象(可能很肤浅)，但我想听听更有经验的开发人员的意见 -- 使用环境变量和命令行参数将参数传递给进程的优缺点是什么？ 我想考虑以下事项:

设计质量(灵活性/可维护性)，

内存限制，

解决方案的可移植性。

备注:

广告。 1. 这是我感兴趣的主要方面。

广告。 2.这有点务实。我知道 Windows 上的一些限制目前是 huge (命令行和环境块都超过 32kB)。我想这不是问题，因为如果需要，您只应该使用一个文件来传递大量参数。

广告。 3. 我对 Unix 几乎一无所知，所以我不确定这两种策略是否与在 Windows 上一样可用。如果您愿意，请详细说明这一点。

Answer 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让我想起了使用全局变量的理由；)

我因亲 body 验环境变量过度使用的恐怖而留下的疤痕

工作中需要的两个程序，由于环境冲突，不能同时在同一台电脑上运行

具有相同名称但存在不同错误的多个版本的程序 - 使整个研讨会瘫痪数小时，因为程序的位置是从环境中拉出来的，并且(悄悄地，微妙地)是错误的。

2) 限制

如果我要突破命令行可以容纳的内容或环境可以处理的内容的限制，我会立即进行重构。

我过去曾将 JSON 用于需要大量参数的命令行应用程序。能够使用字典和列表以及字符串和数字非常方便。该应用程序只需要几个命令行参数，其中一个是 JSON 文件的位置。

这种方法的优点

不必编写大量(痛苦的)代码来与 CLI 库交互——让许多公共(public)库强制执行复杂的约束可能会很痛苦(“复杂”我的意思是比检查一个复杂的约束更复杂)特定键或一组键之间的交替)

不必担心 CLI 库对参数顺序的要求——只需使用 JSON 对象!

易于表示复杂数据(回答 What won't fit into command line parameters?)，例如列表

易于使用来自其他应用程序的数据——以编程方式创建和解析

易于适应 future 的扩展

备注 :我想将此与 .config-file 方法区分开来——这不是用于存储用户配置。也许我应该称其为“命令行参数文件”方法，因为我将它用于需要大量不适合命令行的值的程序。

3) 解决方案的可移植性:我不太了解 Mac、PC 和 Linux 在环境变量和命令行参数方面的区别，但我可以告诉你:

三者都支持环境变量

它们都支持命令行参数

是的，我知道——这不是很有帮助。对不起。但关键是你可以 期望一个合理的解决方案是可移植的，尽管您肯定希望为您的程序验证这一点(例如，命令行参数是否在任何平台上区分大小写？在所有平台上？我不知道)。

最后一点:

正如 Tomasz 所提到的，对于参数来自的大多数应用程序来说应该无关紧要。