Bug Report
What did you do?
Have snakeCaseParameters enabled, and have a resource containing a key in the spec which matches the special words defined here e.g. THIS_IS_SKIP_NOT_SK_IP
What did you expect to see?
The value should be left as is.
What did you see instead? Under which circumstances?
THIS_IS_SKIP_NOT_SK_IP will be converted to THIS_IS_SK_IP__NOT_SK_IP. Can be further confirmed by adding the following test to the paramconv_test.go TestToSnake tests:
{
name: "should not interpret substring as special word",
args: args{"this_is_SKIP_not_SK_IP"},
want: "this_is_skip_not_sk_ip",
}
The result of running this is:
ToSnake() = this_is_sk_ip__not_sk_ip, want this_is_skip_not_sk_ip
Possible Solution
Not attempting to handle mixed case scenarios and assume strings with underscores are already in snake case.
I initially considered taking the following approach:
- If the special word is found at the beginning of the value and is followed by another letter of the same casing, assume it is a substring of another word
- Otherwise if the special word is found at the end of the value and is preceded by another letter of the same casing, assume it is a substring of another word
- Otherwise, if the special word is either preceded or followed by another letter of the same casing, assume it is a substring of another word
This would address the issue for handling cases such as THIS_IS_SKIP, THIS_IS_SKIP_NOT_SK_IP, and IPSUM_LOREM, however taking that approach would result in cases such as IPInterface being incorrectly handled.
Therefore to me it seems the best solution is to cease attempting to handle what I would imagine is an exceptional situation where the value is mixed case (e.g. _CanYou_Handle_mixedVars as seen in the tests).
Bug Report
What did you do?
Have snakeCaseParameters enabled, and have a resource containing a key in the spec which matches the special words defined here e.g.
THIS_IS_SKIP_NOT_SK_IPWhat did you expect to see?
The value should be left as is.
What did you see instead? Under which circumstances?
THIS_IS_SKIP_NOT_SK_IPwill be converted toTHIS_IS_SK_IP__NOT_SK_IP. Can be further confirmed by adding the following test to the paramconv_test.go TestToSnake tests:The result of running this is:
ToSnake() = this_is_sk_ip__not_sk_ip, want this_is_skip_not_sk_ipPossible Solution
Not attempting to handle mixed case scenarios and assume strings with underscores are already in snake case.
I initially considered taking the following approach:
This would address the issue for handling cases such as
THIS_IS_SKIP,THIS_IS_SKIP_NOT_SK_IP, andIPSUM_LOREM, however taking that approach would result in cases such asIPInterfacebeing incorrectly handled.Therefore to me it seems the best solution is to cease attempting to handle what I would imagine is an exceptional situation where the value is mixed case (e.g.
_CanYou_Handle_mixedVarsas seen in the tests).