Updates variable names that do not use mixed caps to be more idiomatic Go code.
In Go, the convention is to use MixedCaps or mixedCaps rather than underscores to write multi-word names. This applies to both exported and unexported identifiers, such as constants, variables, types, fields, functions, etc.
This is not a functional change, but it makes your code more consistent with the style that Go developers expect.
Testing
packer-plugin-vsphere on fix/use-mixed-caps
➜ make generate
2024/06/18 22:39:03 Copying "docs" to ".docs/"
2024/06/18 22:39:03 Replacing @include '...' calls in .docs/
Compiling MDX docs in '.docs' to Markdown in '.web-docs'...
packer-plugin-vsphere on fix/use-mixed-caps
➜ make build
packer-plugin-vsphere on fix/use-mixed-caps
➜ make test
? github.com/hashicorp/packer-plugin-vsphere [no test files]
? github.com/hashicorp/packer-plugin-vsphere/builder/vsphere/common/testing [no test files]
? github.com/hashicorp/packer-plugin-vsphere/examples/driver [no test files]
? github.com/hashicorp/packer-plugin-vsphere/version [no test files]
ok github.com/hashicorp/packer-plugin-vsphere/builder/vsphere/clone 1.529s
ok github.com/hashicorp/packer-plugin-vsphere/builder/vsphere/common 3.295s
ok github.com/hashicorp/packer-plugin-vsphere/builder/vsphere/driver 5.177s
ok github.com/hashicorp/packer-plugin-vsphere/builder/vsphere/iso 2.266s
ok github.com/hashicorp/packer-plugin-vsphere/builder/vsphere/supervisor 3.849s
ok github.com/hashicorp/packer-plugin-vsphere/post-processor/vsphere 2.057s
ok github.com/hashicorp/packer-plugin-vsphere/post-processor/vsphere-template 2.472s
packer-plugin-vsphere on fix/use-mixed-caps via 🐹 v1.22.4 took 30.0s
➜
Description
Updates variable names that do not use mixed caps to be more idiomatic Go code.
In Go, the convention is to use
MixedCaps
ormixedCaps
rather than underscores to write multi-word names. This applies to both exported and unexported identifiers, such as constants, variables, types, fields, functions, etc.This is not a functional change, but it makes your code more consistent with the style that Go developers expect.
Testing
Reference
Effective Go