[Question]: C# naming convention

[Ev4sio]

Description

Dear TensorFlow.Net team,

I hope this message finds you well. I wanted to reach out to inquire about the naming conventions used in TensorFlow.Net and express my curiosity regarding the departure from the established C# style guide. I have noticed inconsistencies in the naming of classes, functions, and even class attributes.

As a user of TensorFlow.Net, I appreciate the effort put into creating a Python-to-C# conversion, which allows developers like me to leverage the power of TensorFlow within the .NET ecosystem. However, I am puzzled by the decision to not adhere to the fundamental principles and conventions of the C# language.

I believe that consistent and well-defined naming conventions contribute to code readability, maintainability, and overall developer experience. Could you kindly provide some insight into the reasoning behind this departure from the C# style guide? I am genuinely interested in understanding the thought process and potential benefits behind this decision.

Thank you for your time and consideration. I look forward to hearing your perspective on this matter.

Sincerely,

Alternatives

No response

[AsakusaRinne]

Hi,

thank you for telling us this concern. :) I guess it's also many other's concern.

As a .NET developer, too, I'd say I can understand your mood. C# uses camel case like SaveModel(string modelName) instead of save_model(string model_name). It's just ok to use tf.net only, but it may be annoying to use with other packages with C# style APIs.

The main reason behind the python-style naming conventions is that python is the most popular language in ML/DL. Firstly, developers transferred from python could just use APIs the same with python. Secondly, when getting some problems, it's easy to refer to docs of tensorflow (docs of tf.net is not complete).

I believe the API style has once provided some convenience because developers with much experience of AI in 3-4 years ago is much fewer than now, so does the documents. Using the python-style APIs makes it easier to get start with tf.net. However, I also agree that the API style is not compatible with common C# development, which leads to some disadvantages.

Now let's discuss about the approach about changing naming conventions. Since tf.net v1.0.0 will come in the next few months, it's possible to introduce some major break changes while making it easy for users to move from v0.x to v1.x. I think completely changing all the APIs is not a good choice and have to find another way. What I can think of is to add a new binding class, for example, using Tensorflow.SharpStyleBinding instead of using Tensorflow.Binding to get C# style APIs. But it's not seemed to cover all the APIs, for example, Tensor.transpose.

The concern of API names could be classified into these four:
A. Class names
B. Function names under tf, tf.keras and so on.
C. Param names.
D. Method names of a object.

The approach above could only cover the B and C. Considering that most of the class names are already camel case, there's still D left no change.

We'll certainly move to change if it is what the community and developers want (maybe a vote is a good choice?). Now we just didn't find a good approach for the API naming conventions. Could you please help with some ideas?

[Ev4sio]

Hi, thanks for the detailed response. Your decision actually reminds me of what the TorchSharp team did. I must admit, I personally view this as a misstep, but I acknowledge that this is merely my own perspective. In my opinion, the purpose of converting a Python framework into C# should be fully realized, adhering strictly to C# conventions. My rationale is that developers who are already comfortable with Python are unlikely to switch to C#, no matter what you do. And C# coders, like me, might look at the code and think it's a bit messy, or the project isn't being handled right. Your response, however, makes it clear that such an impression would be unfounded and merely a bias formed from initial code readings.

I would personally have adhered strictly to C# conventions, fully committing to the shift away from Python in order to enhance performance, both in terms of execution speed and memory management, and simply highlighted the correspondences with the Python framework in the comments of the classes, functions, etc. This way, it would make the TensorFlow documentation easily accessible and usable, while Visual Studio's autocompletion tools could assist in finding the correct C# naming conventions.

Anyway, I'm glad to know you didn't make this choice on a whim. It no longer appears as a significant issue to me, but I'm empathetic towards other C# programmers who might maintain their biases based on initial impressions. But who knows, maybe I'm the only one who feels this way.

I think a vote may be a good idea.

[AsakusaRinne]

#1074 makes the vote and it will be added to readme to let more people know it. Thank you again for your report of this issue!