Query about kebab case recommendation in did state patches

decentralized-identity / sidetree

Sidetree Specification and Reference Implementation

https://identity.foundation/sidetree/spec

Apache License 2.0

438 stars 112 forks source link

Query about kebab case recommendation in did state patches #749

Closed tplooker closed 4 years ago

tplooker commented 4 years ago

It appears throughout the spec in most places we are using snake_case as the convention for any JSON keys, however the did-state-patches section recommends using kebab case is there a rationale for this being different?

OR13 commented 4 years ago

pretty sure @csuwildcat just decided to use them for that section.

the are values not properties, so Im not sure that it matters, and I would also guess that Microsoft cannot change this now, so I suggest we either add a note to the spec warning about the difference or close this issue with no changes to the spec.

Should we add a note?

csuwildcat commented 4 years ago

The spec-wide snake case thing was never about dictating that all values of objects have a certain case (not even sure that's a fruitful endeavor), it was about standard properties, because the convention in JS/JSON land is to use underscored properties for many ergonomic reasons, such as:

Don't have to screw around with bracket property value setting (I just puked in my mouth)
Double clicking an underscored string selects the whole string, not just a segment.
Camel case looks like shit, for example heresSome props with the same letterRight nextTo each other (puked in mouth again)

We could add a note, but I don't personally believe this warrants it.

tplooker commented 4 years ago

Im struggling to understand your rationale here, the above comments appear to advocate for snake_case? however you chose to use kebab-case with the did state patch type values? e.g add-public-keys which is it you prefer as your comments above only really call out camelCase? My issue was there being kebab-case vs snake_case in different parts of the spec

csuwildcat commented 4 years ago

We were only concerned with properties, because there's a clear common convention for them. This wasn't a consideration, but then custom Action types would have a strange look, in my opinion. Is this something we need to break implementation compat to change?

OR13 commented 4 years ago

Agree, closing this issue. @tplooker feel free to reopen, but 10 days and no comments, and a desire not to break compatibility seem like good reasons to close.