参数传递策略 - 环境变量与命令行 [英] Argument passing strategy - environment variables vs. command line

问题描述

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

这两个策略都是我的第一个（也可能很浅），但我想听取更有经验的开发人员的意见 - 以及使用环境变量和命令行参数来传递参数的过程？我想考虑以下事项：

1. 设计质量（灵活性/可维护性），


2. 内存限制，


3. 解决方案可移植性。

---

备注：

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

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

广告我几乎不了解Unix，所以我不知道这两种策略是否可以像Windows一样可以使用。如果您愿意，请详细说明。

解决方案

1）我建议尽量避免环境变量。

环境变量的优点

• 易于使用，因为它们在任何地方都可见。如果许多独立的程序需要一个信息，这种方法会更加方便。

环境变量的缺点

• 难以正确使用，因为它们可以随时随地可见（可删除，可设置）。如果我安装一个依赖于环境变量的新程序，他们是否会踩踏现有的程序？

我的意见

• 对于每个单独调用程序最有可能不同的那些参数使用命令行参数（例如，对于计算n的程序，n


• 使用配置文件作为用户可能合理想要更改的参数，但不是很频繁（即，当窗口弹出时显示大小）


• 谨慎使用环境变量 - 最好只适用于预期不会改变的参数（即Python解释器的位置）


• 您的点它们是全局的，可以从任何地方访问，从架构的角度来看不太优雅，但限制代码量提醒我使用全局变量的理由;）

我的疤痕经历了第一手的恐怖环境变量过度使用

• 我们在工作中需要的两个程序，无法在同一台计算机上同时运行环境冲突


• 具有相同名称但不同错误的多个版本的程序 - 将整个工作坊跪下数小时，因为该程序的位置是从环境中拉出的，而且是（默默地，巧妙地）错误。

---

2）限制

如果我正在推动命令行可以持有的限制或环境可以处理的限制，我会立即重构。

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

此方法的优点

• didn'不得不编写很多（痛苦的）代码来与CLI库进行交互 - 让许多常见的库来执行复杂的约束可能是一个痛苦（复杂的我的意思比检查一个特定的键更复杂或一组键之间的交替）


• 不用担心CLI库对参数顺序的要求 - 只需使用JSON对象！


• 容易表示复杂的数据（回答什么不符合命令行参数？）如列表


• 容易使用其他应用程序的数据 - 无论是以编程方式创建和解析


• ，以适应未来的扩展

注意：我想将其与.config-file方法区分开来 - 这不是用于存储用户配置。也许我应该称之为'命令行参数文件'的方法，因为我使用它需要一个程序，需要很多不符合命令行的值。

---

3）解决方案可移植性：关于环境变量和命令行参数，Mac，PC和Linux之间的区别我不太了解，但是可以告诉你：

• 所有这三个都支持环境变量


• 他们都支持命令行参数

是的，我知道 - 这不是很有帮助。对不起。但关键是您可以希望有一个合理的解决方案可移植，尽管您一定要验证您的程序（例如，命令行参数在所有平台上区分大小写平台？我不知道）。

---

最后一点：

正如Tomasz所说，参数来自大部分应用程序都不要紧。

Most of the applications we developers write need to be externally parametrized at startup. We pass file paths, pipe names, TCP/IP addresses etc. So far I've been using command line to pass these to the appplication being launched. I had to parse the command line in main and direct the arguments to where they're needed, which is of course a good design, but is hard to maintain for a large number of arguments. Recently I've decided to use the environment variables mechanism. They are global and accessible from anywhere, which is less elegant from architectural point of view, but limits the amount of code.

These are my first (and possibly quite shallow) impressions on both strategies but I'd like to hear opinions of more experienced developers -- What are the ups and downs of using environment variables and command line arguments to pass arguments to a process? I'd like to take into account the following matters:

1. design quality (flexibility/maintainability),
2. memory constraints,
3. solution portability.

---

Remarks:

Ad. 1. This is the main aspect I'm interested in.

Ad. 2. This is a bit pragmatic. I know of some limitations on Windows which are currently huge (over 32kB for both command line and environment block). I guess this is not an issue though, since you just should use a file to pass tons of arguments if you need.

Ad. 3. I know almost nothing of Unix so I'm not sure whether both strategies are as similarily usable as on Windows. Elaborate on this if you please.

解决方案

1) I would recommend avoiding environmental variables as much as possible.

Pros of environmental variables

• easy to use because they're visible from anywhere. If lots of independent programs need a piece of information, this approach is a whole lot more convenient.

Cons of environmental variables

• hard to use correctly because they're visible (delete-able, set-able) from anywhere. If I install a new program that relies on environmental variables, are they going to stomp on my existing ones? Did I inadvertently screw up my environmental variables when I was monkeying around yesterday?

My opinion

• use command-line arguments for those arguments which are most likely to be different for each individual invocation of the program (i.e. n for a program which calculates n!)
• use config files for arguments which a user might reasonably want to change, but not very often (i.e. display size when the window pops up)
• use environmental variables sparingly -- preferably only for arguments which are expected not to change (i.e. the location of the Python interpreter)
• your point They are global and accessible from anywhere, which is less elegant from architectural point of view, but limits the amount of code reminds me of justifications for the use of global variables ;)

My scars from experiencing first-hand the horrors of environmental variable overuse

• two programs we need at work, which can't run on the same computer at the same time due to environmental clashes
• multiple versions of programs with the same name but different bugs -- brought an entire workshop to its knees for hours because the location of the program was pulled from the environment, and was (silently, subtly) wrong.

---

2) Limits

If I were pushing the limits of either what the command line can hold, or what the environment can handle, I would refactor immediately.

I've used JSON in the past for a command-line application which needed a lot of parameters. It was very convenient to be able to use dictionaries and lists, along with strings and numbers. The application only took a couple of command line args, one of which was the location of the JSON file.

Advantages of this approach

• didn't have to write a lot of (painful) code to interact with a CLI library -- it can be a pain to get many of the common libraries to enforce complicated constraints (by 'complicated' I mean more complex than checking for a specific key or alternation between a set of keys)
• don't have to worry about the CLI libraries requirements for order of arguments -- just use a JSON object!
• easy to represent complicated data (answering What won't fit into command line parameters?) such as lists
• easy to use the data from other applications -- both to create and to parse programmatically
• easy to accommodate future extensions

Note: I want to distinguish this from the .config-file approach -- this is not for storing user configuration. Maybe I should call this the 'command-line parameter-file' approach, because I use it for a program that needs lots of values that don't fit well on the command line.

---

3) Solution portability: I don't know a whole lot about the differences between Mac, PC, and Linux with regard to environmental variables and command line arguments, but I can tell you:

• all three have support for environmental variables
• they all support command line arguments

Yes, I know -- it wasn't very helpful. I'm sorry. But the key point is that you can expect a reasonable solution to be portable, although you would definitely want to verify this for your programs (for example, are command line args case sensitive on any platforms? on all platforms? I don't know).

---

One last point:

As Tomasz mentioned, it shouldn't matter to most of the application where the parameters came from.

这篇关于参数传递策略 - 环境变量与命令行的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！