使用由周围软件规定的标准。

例如，在我当前的项目中，YAML 文件包含 Python 属性的默认值。由于 YAML 中使用的名称出现在相关的 Python API 中，因此很明显，在这个特定的项目中，YAML 名称应该遵守每个 PEP-8的 Python lower_case_with_underscores变数命名原则。

我的下一个项目可能有一个不同的主流变数命名原则，在这种情况下，我将在相关的 YAML 文件中使用它。

使用 camelCase: https://kubernetes.io/docs/user-guide/jobs/的 Kubernetes

apiVersion，restartPolicy

使用 Snake _ case: https://circleci.com/docs/1.0/configuration/的 CircleCI

working_directory restore_cache store_artifacts

带破折号的 Jenkins https://github.com/jenkinsci/yaml-project-plugin/blob/master/samples/google-cloud-storage/.jenkins.yaml

stapler-class

因此，看起来项目和团队使用他们自己的约定，而且没有一个明确的标准。

从多年经验中得出的一个不太受欢迎的观点:

DR

显然要遵守约定，但我想说的是，遵循在项目的 YML 文件中建立的约定，而不是随依赖关系而来的约定。我敢说，变数命名原则取决于太多因素，以至于无法给出一个明确的答案，甚至无法描述一种好的做法，而只能说“拥有一些”。

全部回答

库可能会随着时间的推移而改变，这会导致在一个配置中出现多种命名约定，这种情况比任何正常的程序员所希望的都要频繁——除非你想引入(并在以后维护)一个全新的抽象层，保持参数变数命名原则的原始状态，否则你不能对此做太多。

比如，如果所有的依赖项都使用一个名为 request_id的参数，那么将你的参数命名为 request-id或 requestId会使它更加独特，更加容易搜索，同时也不会影响名称的描述性。

另外，在不同的名称空间中嵌套多个具有相同名称的参数有时也是有意义的。在这种情况下，也许有理由在现有变数命名原则的基础上发明一种全新的方法，例如:

• order.request-id.format和
• notification.request-id.format

虽然 IDE 可能没有必要区分这两者(因为它能够在名称空间中索引参数) ，但是你可以考虑无论如何为你的同行这样做——不仅是其他可以使用不同 IDE 的开发人员，而且特别是 DevOps 和管理员，他们通常在维护、迁移和部署期间使用不太专业的工具。

最后，我的一位同事提出的另一个好的观点是，可以很容易地将不同的参数名转换为不同的约定，只需要一个 awk命令即可。反过来做显然是可能的，但是数量级更加复杂，这经常在 KISS 倡导者社区引发关于“保持简单愚蠢”到底意味着什么的辩论。

结论是: 做对你和你的团队最明智的事情。