What is the recommended naming convention for Thrift identifiers in order to maximise cross-language compatibility?

Question

Is there a recommended naming convention for identifiers in Thrift?

For example, we had a Thrift IDL written by somebody who's usually a C# programmer. Source code generated from this worked in both C# and Python. However, although Java code could be generated from the same Thrift file there were Java compiler errors everywhere the author of the IDL had given identifiers names that were exactly the same as their types. For example:

enum DataType {
    Text,
    Integer
}

struct Metadata {
    1: string ColumnName,
    2: DataType DataType
}

Note the 'DataType' identifier has the same name as its type, case included. The generated Java code (using the --gen java Thrift compiler option) had compiler errors like this:

Cannot make a static reference to the non-static field DataType

I'm not a C# programmer myself but I understand starting identifier names with capital letters is quite common practice in C#. As it stands we're going to have to change the IDL to use lowercase for the identifier names (e.g., DataType dataType) and regenerate all our clients; but it would have helped if there had been some advice on naming conventions for Thrift identifiers so we wouldn't have run into problems like this for other languages.

BTW I did try --gen java:nocamel but that didn't solve the problem.

Answer 1

There is no enforced or officially recommended naming convention, other than the usual rules for identifiers and what your compiler tells you. Although a number of known conflicts has already some kind of workaround applied, there are still plenty of possibilities for conflicts. You have to find out what works for you.

The single best option is to just rename the conflicting field in the IDL file, or maybe add an underscore. Regarding RPC and serialization, the field name does not matter, only the field ID is important. Thus renaming a field is not a compatibility breaker vis-á-vis the serialized data, only regarding the source code, which is a fixable thing.

---

EDIT: Here is a nice example for an naming issue that is still open. Due to the nature of the problem, it manifests only with one very specific language: Go. You will never run into troubles with that IDL as long as you stick to any other of the languages supported by Thrift. Nevertheless, things like this should be fixed.