robertwb commented on PR #28865: URL: https://github.com/apache/beam/pull/28865#issuecomment-1773491284
> @robertwb -- I believe case sensitivity is important [ have seen that cause more problems and things harder to debug, than the user benefits of being insensitive, but ... ]. Is it time to choose whether we want YAML to use generally upper or lower case? We probably want go-to conventions. > [...] > I'll look in these a little deeper, in case we want to map upper to lower, etc ... but thought this might be worth calling out [ unless I'm just missing a connection in my mental model here ]. Related: I don't recall seeing this in the syntax doc. https://docs.google.com/document/d/10tzBd6yeElucqLN07OI8MguSQYqvRCYhqgVIChjn67w/edit > > Thoughts? Yeah, case sensitivity is a messy question. Here we're trying to represent an enum value (so there's no risk that `raw` and `RAW` and `Raw` are going to be miss-interpreted or should be kept distinct), and there isn't omnipresent IDE support to tell you when you've got it wrong (and no auto-complete either). Generally the conventions we have so far are that yaml keys (type, name, input, config, transforms, etc.) are (case-sensitive) snake_case (though preferring to go with one word), transform types are (again case-sensitive) CamelCase, and config parameters (like other keys) are also snake_case. For enum-style values, the one president we have is the "language" parameter for MapToFields (Filter, etc.) which is lower case (java, python, javacript, etc.) My prefernce would be to be consistent between that and this format parameter if we require specific casing there. I could see this boiling down to a matter of preference though. Perhaps something to ask on the list? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
