Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
Although I have done considerable programming in the past, never with object-oriented language and very little in the past 15 + years... so now that I'm learning NinjaScript, I'm more like a newbie... aside from having a good foundation in logic, concepts and techniques. I'll make note of a few things in this post that are very useful for me in reducing the frustration that comes from learning something as technical, intricate and precise as C# coding.
First, be an unabashed thief and recycler when it comes to code. Find some code that is similar to what you want to do (for instance, maybe you want a moving average to plot a different color for rising versus falling and you find a Stochastic indicator that does this). Then see just how it is coded. This will allow you to get your feet wet without having to read through the User Manual first to see how to do a simple thing. The positive part of that is that it shortens the time to figure out how to do something new. The negative part is that without fully understanding why another did something, you could be reproducing an inefficient approach without realizing it. As an example, you might find code to do what you want that uses a series data structure where a simple integer or double would suffice. Yes, it will work fine, but it puts an unnecessary load on your computer. I wouldn't be too concerned about this initially because as you become more familiar with NT/C#, the reason for doing it this way or that will become apparent. Just keep it in mind and ask questions of more experienced coders. You can start with the wizard if you like. I personally find it a nuisance, but it is a place to start. When I was a professional programmer, I read the manuals cover to cover; but most of us here are focused on trading, not programming, so get what you want done as quickly as possible, learning as you go.
I am certainly NOT advocating stealing someone's work that hasn't been offered to the public domain... I am saying if you want to do something that you find in another indicator or strategy, copy it and play with it... consider coding to be a sandbox where you can experiment with how someone else does something and create your own variation of it.
Second, code incrementally. For instance, if there is a particular function I want to apply in multiple instances (like against multiple stochastic settings), I will code it for the first instance... compile, correct problems, and test it thoroughly before applying it to the others. Then copy and paste for the other instances and adjust the code as needed.
Third, compile frequently... I'm likely to compile 2 or 3 times for a new thing I'm trying. even if simple, so that I will catch problems quickly without facing a long list of compile errors. It may seem obvious to take nibbles and confirm an approach but I've heard others talk about working through pages of compile errors so perhaps not.
Fourth, I like my code organized so I make liberal use of the "#region / #endregion" feature of the NT editor. This creates collapsable sections of code which are "hidden" when you are working on something else.
Fifth, even though I know that eventually I will want a value for a function to be user-enterable, when I'm first coding an indicator, I plug in absolute values. My main goal is to get the concept programmed as a prototype, knowing that I can refine it later for input, error management, etc. It is much more satisfying to know that your prototype works right off the bat without spending a lot of time putting in bells and whistles.
Finally for debugging, I make liberal use of the "Print" statement which displays information in the Output Window (Tools - Output Window). Keep in mind, the fact that code compiles doesn't mean it is doing what you want. Here is a typical print statement for me:
whichChart is only necessary if you are simultaneously testing the code on multiple charts... I create a user variable that allows me to enter a string into the Indicator (or Strategy) input area. For instance I am using a 12R chart for trend/direction, but a 4R chart for entries. If you don't include this, you won't know from which chart the information is being generated. (In this example however, I could also display the Bars.Period value of the chart).
CurrentBar displays which actual bar is generating the information... it is optional and somewhat redundant with Time.
Time[0] displays the time of the bar so you can look at the actual bar generating the information to see if the code makes sense.
Line # displays approximately the line of the code (hardcoded by me). Obviously this changes as you add or delete code and you can put something else in here to help you find which part of your code is printing the information... I just throw that in to help me locate it quickly.
If you really want something to stand out, throw in some "*** " around that area. In fact, if you have a lot of active Print statements in your code, you can start out your code (after "On Bar Update") with a Print statement with all this identifying information along with the asterisks, and then not bother with it in individual Print statements. Then the ID stuff will be displayed for each bar followed by the other displays on subsequent lines. Obviously, as you have debugged an area of code, you can comment out those Print statements or delete them entirely.
When you want to see the results of your indicator or strategy and have a clean compile, open the Indicator Dialogue Box and select it, applying it with "New". If it is already on your chart, open the Indicator box and then click "Ok" for your changes to take effect. You can also click on the chart and press <F5>
If you get compile errors that you simply can't resolve on your own, comment out the offending code entirely and recompile again... this will avoid the dreaded situation in NinjaTrader in which you can't compile or import anything else due to the errors in this particular code.
I hope others will contribute their favorite time and effort savers by posting to this thread.
I agree with you about learning from others. I received my BS in computer science in 1977 and have been trading ever since. Yes, I punched cards!
I learned MT4 in 2007 after coding hundreds indicators for eSignal and TradeStation. I have been labeled a thief because I downloaded FREE MT4 indicators, modified them, renamed them to include "TRO" in the name so they wouldn't step on the original code, and then posted the indicators I modified so all could download them for free. How can you "steal" what is "free"? All the code that I modified contains the originals coder's copyrights and comments.
Be careful because there are those who will vilify you no matter what. I even have internet "stalkers" who have nothing better to do than attack me all over the net especially after a forum decides to ban me. They wait until after I am banned because then I can't defend myself. I haven't been banned on every forum that I have posted on. There are some forum admins who can see past the BS.
I received a google alert that someone posted about one of my systems on this forum. And when I read the post, I found lies, half-truths and misrepresentations. I tried to correct them but my posts were deleted because they were "off-topic" but the offeding post remained. Why is that?
Now here are some coding tips:
1) If you can make it an input, make it an input. Easier to change inputs than code.
2) Assign a value to a variable and use that variable instead of repeating constants, computations, function calls, etc...
3) Use subroutines or functions instead of having the same code over and over and over...
Being a follower is a quick way to get one's feet wet as I mentioned in my tips and tricks post... but I'm interested in knowing your perspective... why do you advocate "don't be a follower"? is it just your style or are you saying it is the "wrong" approach (and why)?