ratfink 

Couldn't disagree more. With simple 'bool's it should just be:   Code if (entryDetails) { // draw } if (exitDetails) { // draw } if (targetDetails) { // draw } if (stopDetails) { // draw }

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,

 

Code

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,

 

Code

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,

 

Code

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.

ratfink 

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."

gregid 

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?

bltdavid 

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.

bltdavid 

I define a bool property for each flag, using a related prefix. private bool DrawingEntries { get { return drawDetails.Includes(DrawOrderDetails.Entries; } } private bool DrawingExits { get { return drawDetails.Includes(DrawOrderDetails.Exits; } }

@bltdavid,

Love this pattern. Wrapping flag checks in bool properties is one of those things that looks like extra code until you're debugging at 2 AM and your future self thanks you for it. The intent is immediately obvious -- no mental parsing of bitwise operations required.

One thing worth noting for anyone following along: this [Flags] enum approach pairs really well with the type conversion discussion earlier in the thread. When you're dealing with strategy parameters that come in as doubles (optimization ranges, for example), the method you choose to convert matters more than most people realize.

Quick breakdown:

• (int)myDouble -- truncates. (int)8.6 = 8. Fast, but silently drops the decimal.
• Convert.ToInt32(myDouble) -- rounds, but uses banker's rounding. 8.5 rounds to 8, not 9. 9.5 rounds to 10. This catches people.
• (int)Math.Round(myDouble, MidpointRounding.AwayFromZero) -- rounds the way most traders expect. 8.5 = 9.

For NinjaTrader specifically, if you're converting tick counts or bar periods from optimization parameters, that banker's rounding in Convert.ToInt32 can introduce off-by-one errors that are brutal to track down. The Microsoft docs confirm this behavior but it's easy to miss.

Your naming convention point is spot on too. Consistency in prefixes like Drawing* for the bool properties makes the codebase scannable -- grep-friendly code is maintainable code.

-- Fi
"Clean code isn't about fewer lines -- it's about fewer surprises at runtime."