When developing an indicator/strategy I makes serval revisions, Rev1, Rev2, Rev3 etc.
What is the best way to create a new revision of an indicator?
Here’s what I’ve been doing:
Open latest revision of the code
Select All
Copy All
Create new Ninjascript window
Paste
Find & Quick replace OldRevisionName with NewRevisionName
Compile the new revision
Rename the indicator.
However, I ran into an issue recently where I created the new revision, but it doesn’t show up as available to insert into a chart. It compiles fine, and it shows up in the list of indicators in the script window, but I can’t insert it on a chart.
Use a version control like git. You can just copy the source code to a file in a directory that uses git and commit it. If you really want to, you can also tag these commits. Once you do this you can look at various versions of your indicator.
Definitely not “Best Practices”. You can start to run into issues if it starts to get more complex and you have multiple similar versions of it. For example, you keep multiple versions but have similar functions or function names. It’ll start to get messy.
If you only have a single main class (the one for the indicator or strategy itself), you won’t have any issues or run into errors. And you don’t need version control either.
Ok. I’ll assume everything is encapsulated within a single class, which can start to get messy too if it gets too long. It seems that the op just creates multiple files and renames them based on the instructions. So there are indicators with the same or similar code in Rev1, Rev2 and Rev3. All of them exist in NinjaTrader. What you suggested essentially just simplifies the process. Let’s say you have Indicator1. You right click and save as Indicator2. You now have both Indicator1 and Indicator2 files with all the duplicate code. So if the op continues on with let’s say Rev10.. now op has 10 versions that are similar with most likely duplicates all over. If you go the version control route via git, you have a single indicator. No duplicate or similar code through 10 indicators that are revisions and you only have a single indicator when selecting it in the list instead of showing 10 different revisions. So… “Best Practices” for revisions? Nope.
It’s common that when you develop an indicator or strategy, after some time you want to add improvements (this is what I understood YourBuddyRob was trying to do).
At that point, you’ll want to back up the original file so you don’t lose it, and apply the changes in a new one.
Now you have two versions that you can run and compare live to see if the improvements are actually worth it.
This is the usual way to evolve an indicator or strategy.
With Git, you’d only have one indicator/strategy and a single active version, so you wouldn’t be able to compare them live.
Code duplication at this level isn’t really an issue. But if you want to avoid it, you can use static classes, delegates, etc. That would be a more advanced programming topic, though, and not really the point here.
Op didn’t mention that op wanted simultaneous revision testing. The point is… “Best Practices” and having 10 similar indicator files that are revisions with similar code is not it, regardless if you are creating something like a utility static class to minimize the code duplication. But hey, if that’s what you want to do then go for it.
Interesting thread. I think simultaneous revision testing is quite important. A/B testing, for example.
Some day I’ll try Git. For now I copy paste (before) code into notepad tab and give it some description at the top. Gets messy quickly, but it’s manageable.
You can start to run into issues if it starts to get more complex and you have multiple similar versions of it. For example, you keep multiple versions but have similar functions or function names. It’ll start to get messy.