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
Although Go advocates for a naming convention which keeps acronyms uppercased, the WebCrypto API doesn't follow such convention. It leads to certain types/constructs having names such as AesKeyGenParams when in proper Go code, it would be expected to be AESKeyGenParams.
So far we have followed the specs convention for structs, and Go's in other places such as for constants.
We should pick one, stick to it, and document it to make maintainers' lives easier 👍🏻
The text was updated successfully, but these errors were encountered:
We should pick one, stick to it, and document it to make maintainers' lives easier 👍🏻
I think WebCrypto does not follow it because it is a JavaScript API that follows its practices. Based on the fact that we're writing in Go and this code is internal code so it doesn't create any issue for the final UX, I would prefer to pick the Go practice.
I prefer to follow the Go conventions too. However, my goal is ultimately that from a user perspective, the naming of exposed Objects, classes, and so is aligned with the WebCrypto specification. I'm unclear whether or not how things are named in Go impacts what is exposed to the user. I need to do a bit of research and experimentation 👀 🧪
Although Go advocates for a naming convention which keeps acronyms uppercased, the WebCrypto API doesn't follow such convention. It leads to certain types/constructs having names such as
AesKeyGenParams
when in proper Go code, it would be expected to beAESKeyGenParams
.So far we have followed the specs convention for structs, and Go's in other places such as for constants.
We should pick one, stick to it, and document it to make maintainers' lives easier 👍🏻
The text was updated successfully, but these errors were encountered: