Consider using idiomatic capitalization in backend interface

[dae]

DroidBackend is currently a mix of snake_case and camelCase names. Presumably the former was picked to more closely match the Python and Rust code, but I'd humbly suggest it would be better to use the more idiomatic camelCase, as that is less surprising, and will let you avoid editor warnings. Anki's TypeScript code uses camelCase too, as does the default codegen for protobuf files in Kotlin/Java.

[david-allison]

I'd like to reopen this for discussion

It feels useful to have the Anki code which mirrors the python be 1:1 in all aspects.

One of our constant maintenance tasks will be to match Anki Desktop's python, and we want this to be done as easily as possible.

With Kotlin, we can get very close to matching the syntax of the python.

Everything else: Absolutely go with idiomatic code.

One of my long-term goals (once we're back to parity) would be linking the files to the Anki Desktop hashes so we ensure we don't miss changes going forwards.

[dae]

My thinking here is that most of the time, developers are not concerned with the intricacies of the backend, and they expect functions/properties to be in the format typical of that language. When developers do need to compare things to the desktop code, it's fairly easy to convert a camelCase name to a snake_case name in your head, and the conversion is unambiguous. Given that the desktop code is a mix of the formats itself (Rust/Python use snake_case; TypeScript uses camelCase; the protobuf definitions use PascalCase for methods, snake_case for properties, and SCREAMING_CASE for enum cases), I'm not sure you could even claim that one format is canonical. Presumably that's the view the protobuf developers took too - the generated Java/Kotlin code uses idiomatic casing instead of trying to match the protobuf definitions.

[david-allison]

Conclusion:

1. camelCase is better for the majority of developers
2. snake_case names are better for developers who are working inside the files, to match functionality with upstream

camelCase should be used by default

An annotation has been added @LibAnkiAlias("is_empty"), to handle (2).

• non-functional: sync Decks with libAnki #15813 -> 49eb38f