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

问题描述

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

这是我对这两种策略的第一个（也许可能很浅）的印象，但我想听听更多有经验的开发者的意见 - 以及使用环境变量和命令行参数传递参数给进程的命令？我想考虑以下事项：

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


2. 内存限制，


3. 解决方案可移植性。

---

备注：

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

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

广告。我几乎不知道Unix，所以我不知道这两种策略是否类似于在Windows上可用。详细说明，如果你愿意。

解决方案

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

环境变量的优点

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

• 难以正确使用，因为它们在任何地方都可见（可删除，可设定）。如果我安装一个依赖于环境变量的新程序，他们会踩在我现有的程序上吗？
>




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


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


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


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






我的疤痕经历过环境变量过度使用的恐惧。






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


• 具有相同名称但不同错误的多个版本的程序 - 因为程序的位置被从环境中拉出，并且（默默地，巧妙地）错了，所以整个车间被跪了几个小时。






---





2）限制





如果我推送命令行可以容纳的限制，我会立即重构。





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



$ b

此方法的优点






• 不得不编写很多（痛苦的）代码来与CLI库交互 - 可能很难获得许多常用库来强制实施复杂的约束（复杂我的意思比检查特定键更复杂或一组键之间的交替）


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


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





$ b $

b

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

---

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

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


• ，它们都支持命令行参数

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

$ b

最后一点： b

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屋！