if you're wrapping a REST api, what factors dictate weather or not you convert all named parameters to kebab-case or just leave it camelCase

these would be in maps users pass to my api wrapper

im leaning towards just keeping {:camelCaseKeywords ...}

If you're writing an api wrapper, I would go with kebab-case. Or you could accept both. But the point of a wrapper is to bring everything into the Clojure world and kebab-case is the naming convention in the Clojure world.

Tangentially, I haven't used an API wrapper for a while. Instead, I like to use https://github.com/oliyh/martian

there's a big thread on clojureverse talking about keywords and boundaries between different systems and languages

@jjttjj I've been thinking about this a lot lately. With a Clojure server (REST HTTP API/SQL DB) I am converting from PostgreSQL column names (snake_case) to Clojure kebab-case and then to JSON snake_case (make it easier for JS clients). I have a function that recursively updates key names at every boundary. Kind of a pain in the butt (and if your JSON/JDBC lib doesn't have a direct hook then you may end up walking the same data structure twice). Edit: my logic was to try to keep each data format in the most idiomatic style for each language/context at the cost of conversion

yeah it makes sense regarding the idioms of the language. What has given me pause lately is that datomic uses camelCase keyword terms

another problem is that it seems like a big waste of time to keep converting things

exactly

it has always bothered me, but it extends a bit beyond just clj since there are so many naming conventions in play

except clj is somewhat “unique” in that it uses kebab-case, which some langs can’t deal with

(for identifiers)

in the past i would always convert things. But there are always edge cases that must be accounted for ("PnL", etc) and effort going into something that at the end of the day doesn't matter a ton

yep

and converting CamelCase like HTTPThing is always fun

h-t-t-p-thing 😛

also not converting allows you to leverage the host docs mabe with a little less mental overhead required for the user

messes up with searching yes

but on the flip-side, if you have a bunch of non-idiomatic keywords in your code, may cause subtle mistakes

(:woops-forgot-this-is-camel-case m)

yeah

I think camel case is the most universally supported... maybe I should just get in the habit of using it more for naming SQL columns and JS objects... would sync with Java naming as well

and just keep the camel case within CLJ

for postgres the pain is having to put everything in doublequotes. for me, having mixed / inconsistent / unidomatic identifiers isn’t that annoying, but having to quote everything is a nightmare

IMO, if the next resting place of the data is in clj/cljs land, kebab it. If you're pulling in json with lots of camels and you have to return the same camel json as fast as possible, converting might be prohibitive, depending on requirements.