A Little piece of treasure for new developers
Don't call it MyBuy(), rather call it IsBuySignal() or something like that. The prefix "My" serves absolutely no purpose, it will only confuse. Make function names descriptive so they immediately tell what they are supposed to do:
if (IsBuySignal()){
DoBuy();
}
Try to follow some common style in naming the functions.
DoSomething() for functions that do something (or other verbs like Plot or Delete or Move)
GetSomething() that calculate or retrieve a value (but don't do any actions)
IsSomething() like above but for boolean (true/false) only.
SetSomething() to permanently change some global value or something like that.
etc.
something along these lines. No matter how exactly you do it, the most important thing is that it is clear from reading the function name alone what it is supposed to do. When reading the name MyBuy() it is not clear what it is supposed to do: does it give a signal or does it trigger the actual buy. IsBuySignal() and DoBuy() are much more descriptive. By using this kind of naming the above snippet of code begins to read almost like plain human language: "If is buy signal [then] do buy". while something like "If my buy then my other buy" or "if my buy then my buy1" or "If my buy then your buy" would sound a bit strange.
awe shucks, I was just throwing in a little hillbilly laziness. The point of the discussion was to focus your trading signal in an organized manor to allow for optimization of code. I personally don't care if they call it SeeSpotRunforBuy() or MyBucketHasAHoleInIt(), as long as the message was clear about being organized with their decision making. Personally, the whole concept of easy to read coding serves 2 purposes, 1 the owner of the company can pass your code to the next coder to pick up where you left off, removing job security from the dev, and ease of exchange for the owner; the second is it is easier for pirates to hack the code. Personally, I miss the old spagetti code, at least you didn't lose your job to a foreigner working for 1/5 your pay.
Personally, I miss the old spagetti code, at least you didn't lose your job to a foreigner working for 1/5 your pay.
bool MyBuy(){ bool upTrend = Eline > Tline; bool beyondResistance = Bid > lastFractal + Confirm.Pips * pips2dbl; ... bool buy = upTrend && beyondResistance ...; return (buy); }
With unreadable spaghetti code as your ideal coding style you would not even have gotten a job in my company in the first place.
Well 13 years at MSFT, you can bet I did not use speghetti code. However, as a business owner and in this particular market, spaghetti codes serves great for keep hackers out of the code.
You don't need to sort the conditions, you only want to open when all are correct. Simplify the code:
When you get into compleex signals and multiple conditions are in play, you will be thankful for using this technique. If you use simple criteria for your trade signals, then there is no need, but as they grow complex, this become very useful.
when I have multiple trade conditions that should be fullfilled to trigger a trade i set a variable for each one then in the code i do
if(this == that && that < something && other > something && that == somethingelse && this != something )
{
then do trade stuff;
and print something;
and set flags:
and whatever else;
}
and in the if conditions I put the least frequent to occur signal first and the most frequest last because I assume the if gets aborted the first time something isnt true so the only time it gets past the first condition would be if it is true.
isnt this the fastest way to set trade conditions ?
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Have you ever been frstrated from trying to establish a trading trigger and for some reason, it still seems to break through and place a bad trade? I wanted to take few moments and offer you this little tidbit I have come to develop an understanding about.
As I am sure you know, this trading system is pretty much a giant loop that has a top to bottom flowthrough. Meaning that the first command is executed, then the next one then the next one.
When you set up a strategy, usually you have several conditions that you want to match up before placing a trade. Because of this, many of us place our trading decisions in some method/function and make a call to it. A decent one basically is a bool function, you test for conditions, if true, then return permission to trade.
How many times have you written your code with just the objective of the main condition in mind, then build the remaining criteria within it? Yeah, me too.
If you were to use a little organizational structure within that function, you would most likely achieve your objective a little more accurately. Let me illustrate for you.
First make a list of all the conditions underwhich you DO NOT want the function to take a trade. For example, I like working with Bollinger Bands. I never want to see a buy open on the top half of the Bollinger bands, so one condition would be if this is a buy opportunity and the price is greater than the Bollinger Median line, then skip the opportunity. Then I would also want one for the sell condition as well. I would not want a sell trade to open below the Bollinger Median.
Now, sort them according to whether they are buy conditions or sell conditions. When you seperate them into different functions, it is a pretty clear choice tree when deciding whether you are targeting a sell or a buy.
New sort them according to priority. What is the most important blocking condition that you want to avoid? Now that you have them in a sorted list and divided by sel or buy functions, Let's take a look at what needs to happen next.
At this point, you have built up a list of all the conditions in which you do not want to trade. These are the conditions to avoid at all costs. You have also set them in order to importance. Now make another list for both buy and sell, in which you want to take a trade. These should not actually be in order of importance so much as in order of frequency. How often will you encounter this condition in the market you are targeting? Here is the reason behind this. Let's say you have 2 strategies in which you want to trade. One might be when you see an engulfing bull you want to buy, otherwise, skip the opportunity. The second one might be, when price crosses the EMA250 going up, you want to buy, otherwise skip the opporutnity. So now one condition might hit many times a day, the other might only hit once a week. If you have the one that only hits once a week being checked for in a higher priority listing, then when that condition is not met, you might not get to trade the daily condition. It is real easy to fall into this crack when you get heavily burdoned with a large amount of coding.
So, now that you have set your negative conditions according to priority and your positive trading conditions according to frequency, in your functions, lay them out like this:
Notice how it follows a nice top down flow through, by setting the negative at the top, you get out without having to process all the extra code. This will help your code to make faster decisions, it will have everything prioritized according to what is important in the conditions of taking the trade. Once you have eliminated all your negative conditions, you are free to focus on the positive conditions that bring the most profits. If the conditions that bring the most profits are not a good fit, then it falls to the next best set of conditions for generating profits, so on and so forth until you have exhausted your choices for good trading conditions, then in the end, it just returns a false and let's you test the other trade direction.
How big of a difference could this mean for you? I have spent this last week doing back testing on some of my conditions. One of my negative conditions took me from a 113 trades in a months period down to 17. When I realized that just because I was allowing this one negative condition in my code, I had more than 90 bad trades that could potentially put me at risk for losses. So, then I found myself in the need of generating more postive trades, because let's face it, watching 17 trades in a months time is like watching paint dry.
So I created a new trading strategy and put it into my functions. The new strategy generated more than 145 trades, but when I initially put it into the function, I put it below the slower condition. So I didn't really notice a difference in earnings. I realized that I hardly ever got to this condition for the purpose of seeing if it worked. That is when it dawned on me. Switch places with them. I reset their priorities according to frequency wrapped them both with a bool condition, which then allowed me to test each one independently or together without having to recompile. this is when I discovered the 145 trades in the same time span. Once this was accomplished, I ran them together and found out that when the higher frequency didn't pan out the otherone had a change to help out and I ended up with over 250 trade potentials for that same monthly period.
But wait a minute, 17 and 145 does not make 250, I guess the lower frequency had a side effect to the higher frequency in that it stayed in trades longer and because of it, it was missing other trades that could have been more profitable and a higher frequency. So in this case, they boosted each others performance. A lesson well learned.
that's it, happy pipping