You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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. 👍
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.
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
helper/validation/<type>
, e.g.helper/validation/string
,helper/validation/int
etc. - that would allow us to omit types from the function names themselvesIs
(e.g.IsEmpty
,IsWhiteSpace
). Our functions do not actually returnbool
, 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.IsUUID
vsIsNotUUID
, orIsValidUUID
vsIsNotValidUUID
. 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.
The text was updated successfully, but these errors were encountered: