Code quality improvement of ETA.NET samples

[vokounjan]

First of all I would like to thank you for your work on the new Real Time SDK. We already use a solution based on RFA.NET in our organization, but we would like to use it on UNIX OS, so your work is very much appreciated.

However, I have been spending the last few days going through and working with the samples provided and I believe that there is quite a lot of room for improvement in the quality of the code which would significantly help other developers.

I had a similar experience a few years ago when I was working with samples based on RFA.NET, but the current experience is even more significant given the evolution of programming standards and the elegance of the new .NET (Core) framework.

I understand that samples are not meant to be production ready, but I believe that the following modifications would significantly help in understanding and therefore better adoption by other developers:

• Use of dependency injection and limiting cross-class modifications. For example, the logic between handlers from EtaAppCommon project is not entirely straightforward and the examples make it even more difficult to understand due to unclear dependencies in the code.

• Use of unified logging instead of calling Console.WriteLine().

• Limiting the use of StringBuilder (and in particular sending it as a parameter to other functions) for logging purposes. It is very difficult to trace where which values come from. Non-printable characters (\n, \t) don't help code readability either.

• Adherence to proper naming conventions. A couple of examples that occur in the code that are in conflict with Microsoft guidelines:

  • Unnecessary abbreviations (Msg instead of Message, wle instead of WatchListEntry, pu instead of PostUserInfo, etc.)
  • Conflicting names (e.g. Int, Double, Float and other classes from Refinitiv.Eta.Codec namespace)
  • Variable names that don't have any meaning (ret)

• Using pure functions where possible. Many functions from the samples depend on class members or modify input parameters quite unnecessarily which also make more difficult to trace the code flow.

• Reducing the number of nested if-statements.

• Use of event-driven programming/callbacks instead of calling Task.Delay() in loops.

Thank you, Jan

[L-Karchevska]

@vokounjan We appreciate your feedback! An internal Jira was created to look into it.

[vlevendel]

Thank you for your feedback, @vokounjan.

We've made a few modifications over time to address some of your concerns and offer the following explanation for others. We also intend to include a readme file (in forthcoming release) that explains dependencies in sample code.

• Due to implementation complexity without returns in performance, we're choosing not to pursue Dependency Injection at this time. Application usage of DI is not precluded by this decision.
• We use StringBuilder so that we can re-use the underlying buffer (avoiding GC)
• Conflicting name: if you'd like to use our primitives, please preface with Eta/Ema namespace