Add known special acronyms to init

[crossplane]

Add known special acronyms to init

[muvaf]

Ugh, it turns out it doesn't run the checker for every word in the string; it just acts like an override map. I'll have to implement a converter for snake_field to CamelCase.

[muvaf]

I opened the PR but I'm having some second thoughts about whether we should do this for json tags. The advantage for users is that they will see nicer json tags, like someRouteTableID instead of someRouteTableId or vpcID instead of vpcId.

The risk is that the list of acronyms won't be full so we might end up in a situation that some fields are properly named, some not and we can't really add things to list because it'd be a breaking API change. Hence users would not be able to get a consistent experience.

cc @negz @ulucinar @turkenh

[muvaf]

Hmm Kubernetes resources do appear to care about this, there is status.podIP field in Pod. But it has status.podIPs as well which made me think that if we get pod_ips, the best we would do would be to convert it to podIps because we cannot really know whether it should be IPs of IPS without context.

[negz]

I'm having some second thoughts about whether we should do this for json tags

The goal is to match the cloud APIs as closely as possible, so I actually think not doing this for JSON tags might make sense in a lot of cases. For example I believe AWS APIs typically use JSON struct fields like vpcId or someArn, not vpcID and someARN. I thiiiiink GCP is like this too - I just checked https://cloud.google.com/sql/docs/mysql/admin-api/rest/v1/instances#DatabaseInstance and I see secondaryGceZone not secondaryGCEZone.

It would still be nice to correctly capitalise the actual Go struct fields in our types, in accordance with typical Go style. I could be convinced it's not the end of the world if it's not possible to do that though - there's plenty of precedent for relaxing style on generated code that humans don't need to interface with as often.