.NET APIs do not follow the C# Conventions

Questions about MultiCharts .NET and user contributed studies.
TopGuy
Posts: 11
Joined: 20 Nov 2012
Has thanked: 1 time
Been thanked: 7 times

.NET APIs do not follow the C# Conventions

Postby TopGuy » 21 Nov 2012

I am a software architect specialised in .NET more than being a trader.

I have spent the last two days looking at the .NET code and I don't think that there is much effort put in place to follow the .NET conventions which adds to the MC.NET APIs learning curve. Some examples from the top of my head are:
- Events that do not use the (Sender, EventArgs) delegates.
- Method names that are shortened to the degree that it is not understood without reading the documentation like CalcBar, is this CalculatedBar? CalculatingBar? (This is a rhetorical question).
- Class names with underscores (this is not in the APIs though, this is in the indicators and strategies)
- ISeries that do not implement IEnumerable (maybe the architect had a good reason why not to).
And more!

The bad news now is that usually a product doesn't change its API after release and we are stuck with this forever, is thre any plan to rectify this?
These users thanked the author TopGuy for the post (total 3):
holyaJoshMorad

User avatar
Dave Masalov
Posts: 1712
Joined: 16 Apr 2010
Has thanked: 51 times
Been thanked: 485 times

Re: .NET APIs do not follow the C# Conventions

Postby Dave Masalov » 21 Nov 2012

TopGuy,

Please provide us with examples of the conventions that are not followed in MC .NET.

TopGuy
Posts: 11
Joined: 20 Nov 2012
Has thanked: 1 time
Been thanked: 7 times

Re: .NET APIs do not follow the C# Conventions

Postby TopGuy » 21 Nov 2012

To be honest, you have some good pieces in place, I should have mentioned them before jumping to criticism. I like the good usage of interfaces that allows me to to mock your classes to aid my unit testing of the strategy. I also liked the usage of the "Input" attribute to mark external input, good use of extension methods,

Here are some points that don't follow the .NET framework conventions:
- Prefixing a class letter with "C" such as CStudyAbstract and CStudyControl , this practice is popular in C++ but never in .NET.
- Suffixing a class with "Abstract" usually a class is suffixed with "Base" and base classes are mostly marked with Abstract
- Using the suffix "Attribute" in most class names, such as PlotAttributes. This suffix should have only been used to mark .NET attributes while it has been used in other scenarios.
- Excessive use of the "Object" suffix such as "SessionObject" , "IndicatorObject", "VariableObject", "IPlotObject", etc... The only object that I can think of from the .NET framework that has the word object is the base Object class. Naming things with Objects is an outdated COM practice such as ADO, DAO, etc...
- Series interfaces and Array interfaces should implement at least "IEnumerable", however, they do not. This is a serious flow in the application because it means all the valuable .NET built-in IEnum lambda expressions cannot be used. I believe that this is made to stay in harmony with MC, but if you don't want to alienate .NET developers the decision should be reassessed.
- Making things shorter sometime is good such as using a short prefix for utility function upper class. Microsoft MVC uses the class "Html", which is 4 characters, as the object that contains all the Html generation helper methods. In your case you made it "PublicFunctions" rather than something very short like "Util" or "Utility".
- Some Events use the "EventHandler" delegate and some don't (such as "event TItemsChanged<T> Deleted" ) which is unnecessarily confusing, why not using the EventHandler in all occasions following Microsoft's convention in ASP.NET, Winforms and WPF?
- InputAttribute accepts a parameter whose name is "m_enumeration" , is that a class member or a parameter?
- Destroy and Dispose on the same class, aren't they the same? which one should we use? (rhetorical questions). Dispose that accepts a parameter (true or false?) shouldn't this one be marked as "internal"?

I could go on and on with more convention violations...

Now saying all that, I still think that MC.NET is valuable and I like its sophisticated UI and good range of brokers. With all that it is stepping above its direct competitor. So, with all my criticism I still like the product and may invest in it. However, I am hoping that the MC.NET architect would reconsider more aligning with .NET spirit and conventions in the next releases.
These users thanked the author TopGuy for the post (total 4):
holyabluejackJoshMorad

Fabrice
Posts: 182
Joined: 14 Jun 2011
Has thanked: 44 times
Been thanked: 30 times

Re: .NET APIs do not follow the C# Conventions

Postby Fabrice » 23 Nov 2012

I own both MC and MC.Net. At the moment I do not use MC.Net because of the lack of programming examples and my knowledge too limited to be quickly efficient. As a new learner of C#, it would be easier to see MC.Net follows the usual C# conventions. If I have to learn a new language, it is better to learn the good way of doing things right at the beginning. So we can hope that MC.Net will adhere as much as possible to these conventions in order to help us to produce "good" code.
Regards.

JosephIM
Posts: 10
Joined: 21 Nov 2012
Been thanked: 1 time

Re: .NET APIs do not follow the C# Conventions

Postby JosephIM » 04 Dec 2012

I have to 100% agree with the critique on the ISeries objects not implementing I Enumerable..

bluejack
Posts: 42
Joined: 02 Aug 2012
Has thanked: 25 times
Been thanked: 27 times

Re: .NET APIs do not follow the C# Conventions

Postby bluejack » 04 Dec 2012

I would be happy to see an improved version of the API. Its early enough to do this step. The longer you wait the more must be changed.
These users thanked the author bluejack for the post:
JoshM

User avatar
Henry MultiСharts
Posts: 8438
Joined: 25 Aug 2011
Has thanked: 1207 times
Been thanked: 2703 times

Re: .NET APIs do not follow the C# Conventions

Postby Henry MultiСharts » 06 Dec 2012

Thank you for your suggestions regarding the object and class names. We will keep this information in mind creating new names in the future. Though we cannot change the current names because of backward code compatibility.

ISeries has no IEnumerable interface because IEnumerable requires the end point of calculation which is impossible to get with ISeries.

User avatar
orad
Posts: 104
Joined: 14 Nov 2012
Has thanked: 40 times
Been thanked: 14 times

Re: .NET APIs do not follow the C# Conventions

Postby orad » 27 Dec 2013

I totally agree with the criticisms about not following .NET coding conventions. It seems to me that the development team coming from a C++ background has continued applying C++ conventions when designing the .NET API. This makes .NET developers uncomfortable in this environment, and I once even wanted to create my own wrapper over MultiChart.NET's with correct conventions but it takes knowing all the details about he API first. I would prefer if a newer version of the API with breaking changes came which was more .NET friendly, than being backwards compatible in the current state. Here's the definite source for .NET coding standards from Microsoft:

Design Guidelines for Developing Class Libraries
http://msdn.microsoft.com/en-us/library/vstudio/ms229042(v=vs.100).aspx

The design guidelines for developing class libraries are for library development that extends and interacts with the .NET Framework. The goal of the .NET Framework design guidelines is to help library designers ensure that their users reap the benefits of API consistency and ease of use by providing a unified programming model that is independent of the programming language used for development. It is strongly recommended that you follow these design guidelines when developing classes and components that extend the .NET Framework. Inconsistent library design adversely affects developer productivity and discourages adoption.


Same stuff from MSDN for .NET Framework 4.5
http://msdn.microsoft.com/en-us/library/ms184412(v=vs.110).aspx

You should also be able to find more concise documents for .NET coding standards on the net.

User avatar
Henry MultiСharts
Posts: 8438
Joined: 25 Aug 2011
Has thanked: 1207 times
Been thanked: 2703 times

Re: .NET APIs do not follow the C# Conventions

Postby Henry MultiСharts » 30 Dec 2013

Thank you for your feedback. It has been forwarded to the management of our company.

CarseWhite
Posts: 21
Joined: 30 Jan 2014
Been thanked: 2 times

Re: .NET APIs do not follow the C# Conventions

Postby CarseWhite » 30 Jan 2014

MC.NET also allows for MSSQL, MYSQL, ORACLE, DBASE, ACCESS, and many other database servers.

Fabrice
Posts: 182
Joined: 14 Jun 2011
Has thanked: 44 times
Been thanked: 30 times

Re: .NET APIs do not follow the C# Conventions

Postby Fabrice » 06 Mar 2014

After having learnt to code in C#, I must agree that using classes that derive from ISeries (VariableSeries etc…) is an absolute nightmare because they do not implement IEnumerable. May be I have missed something, but from what I have understood by experience (and not by the documentation, but that's another lasting issue) we cannot even determine the number of elements of a VariableSeries. Using VariableSeries (and all ISeries-derived classes) do not allow to use "foreach", ".All" ".Count", Linq queries, etc… Well, in short, forget the power of C# and Linq on IEnumerable.

I believe that MC.Net should offer us these abilities when programming in C#, because all experienced C# programmers expect them. Until then, we are left with few choices :
- use ISeries-derived classes, with all the problems above (and others not described here)
- implement ourself our enumerable series, which require to manage the collection (indexes, adding/updating elements according to the tick status - which is not difficult but not trivial). And also, I wonder what will be the result of the collection when doing replay of the chart...

Regards.

User avatar
Henry MultiСharts
Posts: 8438
Joined: 25 Aug 2011
Has thanked: 1207 times
Been thanked: 2703 times

Re: .NET APIs do not follow the C# Conventions

Postby Henry MultiСharts » 14 Mar 2014

All Series variables have the length equal to MaxBarsBack.
These users thanked the author Henry MultiСharts for the post:
Fabrice

Fabrice
Posts: 182
Joined: 14 Jun 2011
Has thanked: 44 times
Been thanked: 30 times

Re: .NET APIs do not follow the C# Conventions

Postby Fabrice » 15 Mar 2014

Hello Henry,

This is what I have finished to understand. May be that should be in the faq near the VariableSeries topic.

Regards.
These users thanked the author Fabrice for the post:
Henry MultiСharts

User avatar
orad
Posts: 104
Joined: 14 Nov 2012
Has thanked: 40 times
Been thanked: 14 times

Re: .NET APIs do not follow the C# Conventions

Postby orad » 04 Dec 2014

I want to suggest the MC.NET team to take a look at Microsoft StreamInsight for designing the time series APIs. It provides a LINQ-style interface for processing complex events such as time series. If MC.NET supports it, or provide an adapter to connect to StreamInsight, that would make a huge advantage over any competitor products for .NET developers.

Also see: LinqPad driver for StreamInsight

User avatar
Henry MultiСharts
Posts: 8438
Joined: 25 Aug 2011
Has thanked: 1207 times
Been thanked: 2703 times

Re: .NET APIs do not follow the C# Conventions

Postby Henry MultiСharts » 08 Dec 2014

orad wrote:I want to suggest the MC.NET team to take a look at Microsoft StreamInsight for designing the time series APIs. It provides a LINQ-style interface for processing complex events such as time series. If MC.NET supports it, or provide an adapter to connect to StreamInsight, that would make a huge advantage over any competitor products for .NET developers.

Also see: LinqPad driver for StreamInsight
Hello orad,

Thank you for your suggestion. It has been forwarded to the management of the company.

User avatar
orad
Posts: 104
Joined: 14 Nov 2012
Has thanked: 40 times
Been thanked: 14 times

Re: .NET APIs do not follow the C# Conventions

Postby orad » 10 Feb 2015

I'm listing the MultiCharts.NET API issues that I notice, here: viewtopic.php?t=48114

Please feel free to add anything else that you find in there. Thanks!

jarym
Posts: 48
Joined: 16 Feb 2015
Has thanked: 11 times
Been thanked: 3 times

Re: .NET APIs do not follow the C# Conventions

Postby jarym » 25 Feb 2015

Henry MultiСharts wrote:ISeries has no IEnumerable interface because IEnumerable requires the end point of calculation which is impossible to get with ISeries.


I don't understand this Henry. My IEnumerable wrapper seems to work: viewtopic.php?f=19&t=48229#p113878 and it does not require any 'end point of calculation'.

Can you explain what I've missed because I want to be sure I have not missed something fundamental?

User avatar
Henry MultiСharts
Posts: 8438
Joined: 25 Aug 2011
Has thanked: 1207 times
Been thanked: 2703 times

Re: .NET APIs do not follow the C# Conventions

Postby Henry MultiСharts » 26 Feb 2015

jarym wrote:
Henry MultiСharts wrote:ISeries has no IEnumerable interface because IEnumerable requires the end point of calculation which is impossible to get with ISeries.


I don't understand this Henry. My IEnumerable wrapper seems to work: viewtopic.php?f=19&t=48229#p113878 and it does not require any 'end point of calculation'.

Can you explain what I've missed because I want to be sure I have not missed something fundamental?
Hello jarym,

In your wrapper you need to explicitly specify the length in barsback as the end point for iterations. I.e. there is additional information/parameter for creating IEnumerator<double> iterator. While the standard method IEnumerable.GetEnumerator does not provide any extra parameters. That is why it is not possible to add IEnumerable support for ISeries.
These users thanked the author Henry MultiСharts for the post:
jarym

jarym
Posts: 48
Joined: 16 Feb 2015
Has thanked: 11 times
Been thanked: 3 times

Re: .NET APIs do not follow the C# Conventions

Postby jarym » 26 Feb 2015

Thanks Henry, I get your explanation but then I'd ask you to consider including a wrapper similar to the one I've done - it makes your API immeasurably more useful with the rest of the .NET framework.
These users thanked the author jarym for the post:
orad


Return to “MultiCharts .NET”