Plugin Naming Style Guide
This document explain the best practices and recommendations for naming kubectl plugins. These guidelines are used for reviewing the plugins submitted to krew-index repository.
Plugin names must be all lowercase and separate words with hyphens. Don't use camelCase, PascalCase, or snake_case; use kebab-case.
Plugin names should not be verbs/nouns that are generic, already overloaded, or possibly can be used for broader purposes by another plugin.
kubectl login: Tries to put dibs on the word.
kubectl ui: Should be used only for Kubernetes Dashboard.
Try to find a unique name for your plugin that differentiates you from other possible plugins doing the same job.
kubectl view-logs: Unclear how it is different than the builtin "logs" command, or many other tools for viewing logs.
kubectl tailer: Unique name, points to the underlying tool name.
Use Verbs/Resource Types
If the name does not make it clear (a) what verb the plugin is doing on a resource, or (b) what kind of resource it's doing the action on, consider clarifying unless it is obvious.
kubectl service: Unclear what this plugin is doing with service.
kubectl open: Unclear what it is opening.
kubectl open-svc: It is clear the plugin will open a service.
Prefix Vendor Identifiers
Use the vendor-specific strings as prefix, separated with a dash. This makes it easier to search/group plugins that are about a specific vendor.
kubectl ui-gke: Makes it harder to search or locate in a plugin list.
kubectl gke-ui: Will show up next to other gke-* plugins.
Avoid repeating kube[rnetes]
Plugin names should not repeat kube- or kubernetes- prefixes to avoid stuttering.
kubectl kube-node-admin: "kubectl " already has "kube" in it.
Avoid Resource Acronyms
Using kubectl acronyms for API resources (e.g. svc, ing, deploy, cm) reduces readability and discoverability of a plugin more than it is saving keystrokes.
kubectl new-ing: Hard to spot and the plugin is for Ingress.
If you have suggestions to this guide, open an issue or send a pull request.