Skip to content

poc: generic naming convention linter #106

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

everettraven
Copy link
Contributor

just a proof-of-concept to show an idea of what a generic field naming convention linter could look like

Signed-off-by: Bryce Palmer <bpalmer@redhat.com>
@k8s-ci-robot k8s-ci-robot requested a review from jpbetz June 25, 2025 19:55
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: everettraven
Once this PR has been reviewed and has the lgtm label, please assign jpbetz for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot requested a review from sivchari June 25, 2025 19:55
@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jun 25, 2025
@everettraven
Copy link
Contributor Author

Just a PoC, not mergeable

/hold

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jun 25, 2025
Comment on lines +44 to +88
var defaults = []NamingConvention{
{
Matcher: *regexp.MustCompile("(?i)phase"),
Operation: "Drop",
Message: "phase fields are deprecated and discouraged. conditions should be used instead.",
},
{
Matcher: *regexp.MustCompile("(?i)timestamp"),
Operation: "Replace",
Message: "prefer use of the term 'time' over 'timestamp'",
// replacement of `Time` follows CamelCase principles for field names and JSON tags
// TODO: Handle case where it is _not_ the second word in CamelCase for json tag
Replacement: "Time",
},
{
Matcher: *regexp.MustCompile("(?i)reference"),
Operation: "Replace",
Message: "prefer use of the term 'ref' over 'reference'",
// replacement of `Ref` follows CamelCase principles for field names and JSON tags
// TODO: Handle case where it is _not_ the second word in CamelCase for json tag
Replacement: "Ref",
},
}

type NamingConvention struct {
// Matcher is a regular expression
// used to identify field names
// where this convention applies
Matcher regexp.Regexp

// Replacement is an optional
// string value used to replace the matched content
// in a suggested fix.
// Only used when Operation is Replace.
Replacement string

// Operation is the type of operation that should take place for this
// naming convention.
// One of Drop, Replace.
Operation string

// Message is the message that should be included in the
// linter report when this naming convention is applied.
Message string
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we were to continue with this approach, the thinking is that we would implement a configuration layer for this linter that exposes this NamingConvention type to allow the development of custom naming conventions.

We could also add a configuration option to include/exclude the defaults we have put in place based on the Kubernetes API conventions doc.

@everettraven
Copy link
Contributor Author

/cc @JoelSpeed @sivchari - I'm curious about your thoughts here.

@Karthik-K-N - just a heads up since you have #105 open and I took some liberties to include that convention in this example as well. I don't think this should block your PR from going in (or supersede it). Also happy to hear your thoughts if you have any here.

@Karthik-K-N
Copy link

Even I thought a bit about covering multiple linters under a cover, We have few linters doing similar things like nophase, notimestamp, noduration. Only thought came to my mind at that time was, what if user wants to relax one among many linterns. But with your approach of having a configuration file would be handy at that time.

@JoelSpeed
Copy link
Contributor

I'm a fan of the approach being taken for the NoNullable linter, where we still have a top level linter that contains the descriptions and reasoning of why we do/don't do certain things, but under the hood is just configuring another linter. Perhaps we can do similar here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants