Skip to content
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

Set a naming convention for validation functions #298

Closed
radeksimko opened this issue Jan 15, 2020 · 2 comments
Closed

Set a naming convention for validation functions #298

radeksimko opened this issue Jan 15, 2020 · 2 comments

Comments

@radeksimko
Copy link
Member

With more validation functions coming in (#294 #296 ) it makes sense to think about defining some conventions around the names and perhaps a hierarchy.

Ideally the convention should be easy enough to understand that it is obvious for newcomers where does a new validation function go and what it should be called.


Ideas

  • move functions under helper/validation/<type>, e.g. helper/validation/string, helper/validation/int etc. - that would allow us to omit types from the function names themselves
  • it is a common convention in many languages and codebases to prefix functions that have "boolean outcome" with Is (e.g. IsEmpty, IsWhiteSpace). Our functions do not actually return bool, but technically have boolean-ish outcome (validation will pass or not, but may return warnings). We should discuss whether it makes sense to adopt this convention.
  • Until we have a better story around negation of validation function our convention has to account for dedicated negated versions of functions. e.g. IsUUID vs IsNotUUID, or IsValidUUID vs IsNotValidUUID. i.e. the function name should communicate whether it's positive or negative validation.

I'm not setting any of these proposal to stone yet, but rather creating this issue as a space for discussion about it.

@bflad
Copy link
Contributor

bflad commented Mar 16, 2022

Aye, if I recall, there was some efforts to do this as part of the version 2 major update. However, we do not intend to further extend these validation functions for this SDK and instead we will focus on creating validation naming conventions for terraform-plugin-framework (potentially not including them in the SDK codebase itself). A good place to track that discussion would be hashicorp/terraform-plugin-framework#240. 👍

@bflad bflad closed this as completed Mar 16, 2022
@github-actions
Copy link

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 16, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants