自从您询问经验以来，我已经看到了您建议使用的所有三种方法。然而，最佳实践是代码的输入和代码框架本身是分开的。这意味着只有您不希望更改的参数才应该被硬编码到您的源代码中。例如，如果您正在模拟炮弹的飞行，您可能会硬编码重力加速度的值，但不能硬编码炮弹的半径，它构成了单个模拟的元数据的一部分。这样一来，您的版本控制系统中的代码库就不会被输入数据污染，并且可以让其他人（或六个月后的您）理解。

就类而言，与模拟输入数据的配置文件相比，这实际上取决于所使用的语言以及您是在开发可执行文件还是框架。同样，最佳实践是对配置文件使用 xml 或 JSON 之类的自文档系统（无需滚动您自己的实现，那里有预构建的解析库）。理想情况下，该文件应该是人类可读的，无论是直接还是通过辅助实用程序。对于基于类的方法，属性名称应该再次是人类可以理解的，尽管仍然有人停留在 FORTRAN 66 结构的六字母变量名称中，例如“GRNEW4”。

输出应该再次采用常用的自描述文件格式，并且理想情况下应该包括足够的元数据，以便能够在必要时重现生成它的原始输入数据。由于输入文件与输出数据相比往往较小，因此一种选择是简单地将输入文件/源添加到输出数据的开头。

最终输出的组织方法可能是大多数争论的焦点。虽然版本控制系统对输入文件工作得很好（记住在与源代码不同的存储库中），但它们并不总是能很好地处理二进制数据。这导致了许多基于磁盘的组织（使用人类可以理解的文件名！），但一个有用的可能性是利用各种通用参考管理器之一，如 JabRef，它们很容易获得并提供模拟元数据的可搜索跟踪。

我不知道您可以做些什么来跟踪参数和结果，尽管@origimbo 正确地指出，可重复性有点使结果无法存储。

您提出的第一点显然是版本控制问题，因此解决方案很简单：在 Github 或 Bitbucket 或 Mercurial 上创建存储库。这些服务非常有效，如果您弄乱了代码并且需要恢复它，它们可以让您撤销给定的提交。大多数 IDE 都支持它们作为插件。

另外：云上的冗余！制作备份副本将比通常情况下要少一些。

编辑：在您的程序中实现一个记录器。

switch使用语句管理参数：每个参数case都是一组独立的参数。这并没有解决不同的表达式/代码等，但是对于 Barba 的 12 个步骤，到目前为止就足够了。代码的不同部分的编辑和任意布尔开关（例如不同的边界条件；关闭一个阶段，如平流）。凌乱但灵活。

将参数添加到输出图：因此输入和可解释的结果一起记录在图像文件中。

自动为绘图图像添加时间戳，并输出到 tmp 目录，因此我可以在需要时返回它们（并复制并重命名我想要保留的任何内容）。这是日记的想法；而且，我猜是“记录”的一种形式。

我gnuplot用于绘图，并将参数和文件名作为“调用”参数发送（此行是从我的模拟代码自动生成的）：

gnuplot -c myscript filename stringofparameternamesandvalues

这些参数在脚本中可用作 ARG1 和 ARG2。在脚本中，我为它们设置了输出文件和标题。也可以将它们放在标签中，并将其定位（并\n用于多行），但我担心它有时会覆盖部分情节 - 使用标题可以防止这种情况。

思想：一个参数对象。使用反射，可以自动序列化为 JSON（或 XML），或输出到记录器（如@GoGoLander 建议的那样）。一个优点是，如果您向对象添加新参数，则不必记住将其添加到输出代码（序列化程序会自动输出对象的所有字段）。虽然这不会捕获表达式/代码。编辑参数对象是冗长的，因为必须添加前缀（例如params.dx）。相反，使用代码自己的实例对象上的字段作为参数，并且可以直接使用它们（例如dx）。这是一种在 java 中自动输出它们的方法（假设没有其他字段）：

import java.lang.reflect.Field;
...
    public String getParams() {
      String a = "";
      try {
        for (Field f : this.getClass().getDeclaredFields()) {
          f.setAccessible(true);  // so needn't make fields public
          a += f.getName() + "="+ f.get(this) +", ";
        }
      } catch (Exception e) { e.printStackTrace(); }
      return a;
    }

我认为“2. in a class”是编译语言的正确方法，因为它可以存储表达式和代码，并将实验配置与主代码分开。