规范的 YAML 命名风格是什么

Question

我正在设计一个新的YAML文件，我想使用最标准的命名风格。是哪一个？

烤肉串盒？

- job-name:
    ...

蛇箱？

- job_name:
    ...

驼峰式？

- jobName:
    ...

Answer 1

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

例如，在我当前的项目中，YAML 文件包含 Python 属性的默认值。由于 YAML 中使用的名称出现在关联的 Python API 中，因此很明显，在此特定项目中，YAML 名称应遵循 PEP-8 的 Python

lower_case_with_underscores

命名约定。

我的下一个项目可能有不同的流行命名约定，在这种情况下，我将在关联的 YAML 文件中使用它。

Answer 2

使用驼峰命名法的 Kubernetes：https://kubernetes.io/docs/user-guide/jobs/

apiVersion

，

restartPolicy

CircleCI使用snake_case：https://circleci.com/docs/1.0/configuration/

working_directory

restore_cache

,

store_artifacts

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

stapler-class

---

所以看起来项目和团队都使用自己的惯例，并且没有一个明确的标准。

Answer 3

根据多年经验得出的不太受欢迎的观点：

TL；博士

显然要遵守约定，但恕我直言，请遵循项目 YML 文件中建立的约定，而不是依赖项附带的约定。我敢说命名约定取决于太多因素，无法给出明确的答案，甚至无法尝试描述除了“有一些”之外的良好实践。

完整答案

库可能会随着时间的推移而发生变化，这会导致在一个配置中出现多种命名约定，这比任何理智的程序员所希望的都要频繁——你对此无能为力，除非你想引入（并稍后维护）一个全新的抽象层，专门用于那：保持参数命名约定原始。

为什么您会在配置与依赖项附带的配置中想要不同的命名约定的一个例子是可搜索性，例如如果所有依赖项都使用名为

request_id

的参数，则将您的依赖项命名为

request-id

或

requestId

将使其清晰且易于搜索，同时不会损害名称的描述性。

此外，有时将多个具有相同名称的参数嵌套在不同的命名空间中也是有意义的。在这种情况下，基于一些现有的命名约定发明一个全新的命名约定可能是合理的，例如：

• order.request-id.format

  和

• notification.request-id.format

虽然您的 IDE 可能没有必要区分这两者（因为它能够在命名空间内对参数进行索引），但您可能会考虑这样做，作为对您同行的礼貌 - 不仅是可以使用不同 IDE 的其他开发人员，而且尤其是 DevOps 和管理员，他们在维护、迁移和部署过程中通常使用不太专业的工具。

最后，我的一位同事提出的另一个好点是，可以使用像一个

awk

 命令这样简单的命令轻松地将独特的参数名称转换为不同的约定。反过来做显然是可能的，但要复杂一个数量级，这经常会在 KISS 倡导者社区中引发关于“保持简单愚蠢”真正含义的争论。

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