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)
No worries, I love these back & forth ideas on code organization (aka "readability").
I have not done the extension for the enumeration type, but I really like that idea.
ratfink reminds me how I actually check my DebugFlags enumeration. I define a bool property for each
flag, using a related prefix.
In this case, I might do,
private bool DrawingEntries { get { return drawDetails.Includes(DrawOrderDetails.Entries; } }
private bool DrawingExits { get { return drawDetails.Includes(DrawOrderDetails.Exits; } }
private bool DaawingTargets { get { return drawDetails.Includes(DrawOrderDetails.Targets; } }
private bool DrawingStops { get { return drawDetails.Includes(DrawOrderDetails.Stops; } }
private bool DrawingEntriesExits { get { return drawDetails.Includes(DrawOrderDetails.EntriesExits; } }
private bool DrawingEntriesExitsTargets { get { return drawDetails.Includes(DrawOrderDetails.EntriesExitsTargets; } }
private bool DrawingEntriesExitsStops { get { return drawDetails.Includes(DrawOrderDetails.EntriesExitsStops; } }
private bool DrawingEntriesExitsTargetsStops { get { return drawDetails.Includes(DrawOrderDetails.EntriesExitsTargetsStops } }
private bool DrawingEntriesTargets { get { return drawDetails.Includes(DrawOrderDetails.EntriesTargets; } }
private bool DrawingEntriesStops { get { return drawDetails.Includes(DrawOrderDetails.EntriesStops; } }
private bool DrawingExitsTargets { get { return drawDetails.Includes(DrawOrderDetails.ExitsTargets; } }
private bool DrawingExitsStops { get { return drawDetails.Includes(DrawOrderDetails.ExitsStops; } }
private bool DrawingTargetsStops { get { return drawDetails.Includes(DrawOrderDetails.TargetssStops; } }
which turns ratfink's code suggestion into this,
if (DrawingEntries)
{
// draw
}
if (DrawingExits)
{
// draw
}
if (DrawingTargets)
{
// draw
}
if (DrawingStops)
{
// draw
}
but I'd probably not make every combination an enumeration in this kind of example. Obviously the
first 4 are the base members, so another idea is to define just the 4 base members inside the
enumeration, and then define 4 properties for those members. This gives combinations that are
spelled out in the code, at the point of use, and it's also pleasant to read, too.
For example,
if (DrawingEntries || DrawingExits)
{
// same as DrawingEntriesExits
}
if (DrawingExits || DrawingStops)
{
// same as DrawingExitsStops
}
if (DrawingEntries || DrawingExits || DrawingTargets || DrawingStops)
{
// same as DrawingEntriesExitsTargetsStops
}
Great ideas, all of these ... as always, naming consistency is key, regardless of methods/conventions chosen.
Often in the desire to be with the OO street kids we miss the elephant in the room.
I think you missed this part:
"The example is quite naive and could be solved with 4 bools - this is just to show how it works so you can use it for more complex problems."
I think you missed this part:
"The example is quite naive and could be solved with 4 bools - this is just to show how it works so you can use it for more complex problems."
No, the example shows advanced ideas, using 4 bools is naive.
I think your example is very good because it shows how to solve limitations with NinjaTrader backtesting.
NinjaTrader cannot optimize bools in the Strategy Analyzer, and having 4 bool properties exposed in the property grid is a bit overkill.
The solution?
Expose a single int property which is the bit pattern for the [Flags] enumeration type.
The user would add bit values together to produce the "pattern" representing the desired combination.
And, since this is an int property, it's fully optimizable.
I've done that many times, see screenshot for how the user selects their desired TradeDays in my strategy property grid.
PS: I use multi-line descriptions for my property help, does everyone know how to do that?
Expose a single int property which is the bit pattern for the [Flags] enumeration type.
The user would add bit values together to produce the "pattern" representing the desired combination.
And, since this is an int property, it's fully optimizable.
I think I first saw this technique in a Woodies demo strategy I downloaded a few years back.
Woodies stuff is built by MicroTrends using (I presume) their strategy framework product.
Anyways, when I saw it in the Woodies' property grid, I immediately knew what MicroTrends had done (and why) and set about to do the same thing for my strategies.
I still like naive when it just means simple, we overcomplicate far more than necessary so many times. It is interesting to see sophisticated approaches to tackling complex problems, but at my age it has to be KISS.