Best practices

Do not deploy Source Files

If you are a commercial vendor, you should never distribute the source code files even if your IP is contained within an assembly or proprietary DLL. Source code files are editable by users and can result in unnecessary support issues.

Naming Conventions

Please use a consistent naming convention with your indicators and strategies. We suggest adding a prefix to the name. If your company name is “Hyper” you could name your indicator “HyperTrend” or “HyperOscillator” for example.

In the event that you provide an app that has no unique name, it could overwrite an already installed assembly distributed by someone else.

Expose Indicator States

If your proprietary indicator acts as a trend state (green bars are bullish, red bearish) its good practice to expose the indicators state so that consumers of your indicators can use them within their own custom indicator or strategy.

Document your code with XML comments

If your code has any public types or members, it's a good practice to document them with XML comments. This allows other developers to use IntelliSense to show quick information about those types or members and help them understand how to use them.

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/xmldoc/

Test on Legacy Operating Systems

Some customers run on older Operating Systems (such as Windows 7) and you should make sure that your indicators, custom installers and external DLLs (if any are used) properly run on these legacy operating systems.

Last updated