Arcata, CA
Experience: Intermediate
Platform: NinjaTrader
Trading: index futures, oil
Posts: 485 since Jun 2009
Thanks Given: 232
Thanks Received: 415
|
Here is my first cut at suggested coding standards for futures.io (formerly BMT). I welcome comments and suggestions... following these simple guidelines will save us all a frustrating experience such as RJay posted today.
1. If you are modifying someone else’s indicator (or strategy), first rename it, by:
- right click and select “Save As”; enter a descriptive name and assign a version number. Include a mneumonic that identifies you "RJay" preferably before the version number.
- whether starting from an existing code file or from scratch, use appropriate names and version numbers:
- Version numbers:
- NT doesn’t like periods in the name so use underscores; like this: “_v1_0” at the end of the name. The first number, “1” in this case, designates a major version; the 2nd number, “0” in this case, designates minor changes (tweaks).
- Change the names: i. at minimum change “public class nnn_RJay_v1_0 : Indicator” - also good idea to change the name in “[Gui.Design.DisplayName(“nnn_RJay_v1_0”)]; this will avoid confusion in knowing which indicator version is on a chart as this is the name that is displayed in the Indicator list for a chart.
2. Description and logging changes
- In the summary area, enter a description of the code
- Indicate which external files it references “SMA(Close, Period)” for instance, so the user knows what else is required to successfully use the indicator.
- Mention what the source code was, “based on ADXVMA” for instance.
- Log changes as you make version releases: for example: “2009 09 16 – Saroj - added capability of sound alerts”
- Include the name since others might make changes if a collaborative effort; this way, if there is a subsequent problem that person can be consulted.
3. Include liberal comments to create a pseudo code type understanding of the logic (not really necessary for very simple code files, but very helpful none-the-less; especially if someone else might be making changes later.
4. Organize routines by using “#region … #endregion” tags to make the code easier to read (Optional but helpful for complex code)5. Be sure you get a clean compile before closing the file. If you can’t resolve an error, comment it out with an explanation. NT will not allow any other compiles if even ONE indicator has an error in it.
|