命令行参数或配置文件?

Car*_*nco 12 parameters configuration command-line

我正在开发一种可以执行多种分析的工具,每种分析都可以有不同程度的彻底性.此应用程序在开始之前将有相当多的选项.我开始使用配置文件来实现它,因为指定的分析类型的数量很少.随着实现的选项数量的增加,我创建了更多的配置文件.然后,我开始混合一些命令行参数,因为一些选项只能是标志.现在,我将一堆命令行参数与配置文件混合在一起,觉得我需要重构.

我的问题是,何时以及为什么要使用命令行参数而不是配置文件,反之亦然?

它可能与您使用的语言,个人偏好等有关?

编辑:我正在开发一个可以在Windows和Mac上运行的Java应用程序.我现在没有GUI.

Vla*_*lad 9

命令行参数对于从配置文件快速覆盖某些参数设置非常有用.同样,如果没有那么多参数,命令行参数也很有用.对于您的情况,我建议您将参数预设导出到命令行.


Dej*_*avu 5

命令行参数:

优点:

  1. 简洁 - 无需自己维护额外的配置文件
  2. 与 bash 脚本的良好交互——例如变量替换、变量引用、bash 数学等。

缺点:

  1. 随着选项变得更加复杂,它可能会变得很长
  2. 格式不灵活 - 除了一些命令行实用程序可以帮助您解析高级开关等,任何更复杂的(例如嵌套结构化信息)都需要自定义语法,例如使用 Regex,并且结构可能非常严格 - 而 JSON 或 YAML 会很难在命令行级别指定

配置文件:

优点:

  1. 它可以非常大,只要你需要它
  2. 格式更灵活 - 您可以使用 JSON、YAML、INI 或任何其他结构格式以更人性化的方式表示信息

缺点:

  1. 与 bash 变量替换和引用(以及 bash 数学)交互不灵活 - 如果您希望配置文件“通用”且可重用,您可能必须定义自己的替换规则,而这是使用命令行的最大优势参数 - 在配置文件中变量数学会很困难(如果不是不可能的话) - 你必须在配置文件中定义你自己的“运算符”,或者你必须依赖另一个 bash 脚本来执行变量数学,并执行你的自定义变量替换,因此“通用”配置文件可以成为“具体可用”。
  2. 对于准备好通用配置文件(带有自定义定义的变量替换规则)所需的一切,仍然需要一个 bash 脚本来执行实际替换,并且您仍然需要编写命令行以接受所有变量替换,所以要么你有没有变量替换的配置文件,这意味着你“硬编码”并为不同的场景重复配置文件,或者具有自定义变量替换规则的替换逻辑使你的应用程序内配置文件逻辑更加复杂。

在我的用例中,我认为能够在 bash 脚本中进行变量替换/引用(以及 bash 数学)更重要,因为我使用相同的二进制文件来启动服务器后端集群中具有不同职责的许多服务器节点,我有点使用 bash 脚本作为一种容器或实际上是一个配置文件,以使用不同的命令行参数启动许多不同的节点。