A Better Way To Code II - TheRumpledOne

New comment
 

A Better Way To Code III think MT4 chart programs should be split up into 2 types:

1) DISPLAY or FRONT END

2) WORK or CALCULATORS

The display programs would be:

1) Chart window plot

2) Separate window plot

3) DASHBOARD

4) Digital Compass

5) Gauge

6) Meter

7) Multi Meter

8) History bars

The work programs are where the MACD, MA, RSI, etc... calculations are performed.

This way, with standards in place and adhered to, the display programs would only be written ONCE.

The user would tell the display programs what work program(s) (indicators) to use. The display programs would call the internal functions or call the external functions.

An example is the TRO MULTIPAIRS SAK that I coded using mladen's and coderguru's code:https://www.mql5.com/en/forum/178406/page3

To me, it is a waste of time coding the same display functions over and over and over again when all of it can be avoided in the first place. I have done this on other platforms and on MT4, too.

To make this really work, STANDARDS have to be in place. For example, I use 1=up, 0=flat, -1=down. Others use 1=up, 0=down. I got around this by having inputs for up,flat,down. But that's still a pain because if you forget to match the inputs to the program, INVALID RESULTS are displayed.

Thoughts?

Comments?

 

I totally agree that standards would be very helpful, and not just when it comes to charting applications either.

For example, take OrderSend(). When people first start coding EA's they believe that in order to send an order all that has to be done is to call OrderSend(). However, that is not really adequate, imho. There are a lot of other things to worry about like error handling, disconnect handling, logging, and synchronization between EAs (only one trade context available, but multiple threads competing for the resource). If you're going to write a long-running application (such as automated trading), then you need to concern yourself with these things. So, one thing that I've done is to write a SafeOpenOrder() function that I re-use. The idea that the standard MQL library provided is adequate is very far from the truth.

It would be good, imo, to have a community-developed standard library. That's why I've thought about doing the open-source project for some time now, and your posts today prompted me to actually get off my butt and start organizing some things for it.

Anyway, I also agree with you that it would be a good thing to have basically a standard MVC architecture to fall back on (I've also begun working on a unit-testing library myself). The types of displays that you suggest...a few I haven't seen done before in MQL, but that doesn't mean it can't be done.

Personally, I use these defines:

#define DIRECTION_FLAT 0

#define DIRECTION_LONG 1

#define DIRECTION_SHORT 2

BW

 
bwilhite:
I totally agree that standards would be very helpful, and not just when it comes to charting applications either.

For example, take OrderSend(). When people first start coding EA's they believe that in order to send an order all that has to be done is to call OrderSend(). However, that is not really adequate, imho. There are a lot of other things to worry about like error handling, disconnect handling, logging, and synchronization between EAs (only one trade context available, but multiple threads competing for the resource). If you're going to write a long-running application (such as automated trading), then you need to concern yourself with these things. So, one thing that I've done is to write a SafeOpenOrder() function that I re-use. The idea that the standard MQL library provided is adequate is very far from the truth.

It would be good, imo, to have a community-developed standard library. That's why I've thought about doing the open-source project for some time now, and your posts today prompted me to actually get off my butt and start organizing some things for it.

Anyway, I also agree with you that it would be a good thing to have basically a standard MVC architecture to fall back on (I've also begun working on a unit-testing library myself). The types of displays that you suggest...a few I haven't seen done before in MQL, but that doesn't mean it can't be done.

Personally, I use these defines:

#define DIRECTION_FLAT 0

#define DIRECTION_LONG 1

#define DIRECTION_SHORT 2

BW

Thanks for replying.

I have done all of those display types in MT4. Check the threads that I started to see examples.

What MT4 really needs (and almost all languages for that matter) is to take a page from the mainframes and have a /COPY library so the compiler copies in standard code. That way if you have to make a code fix or enhancement, you don't have to change it in every program, only in the /COPY library.

Perhaps we code post source code templates and people can learn from each other.

Then perhaps we could have a standard... but not if SHORT = 2! LOL!!

 

Intuitive Coding

Short is down, so Short = -1 is effortless to remember.

When there is a choice, the intuitive choice makes life easier!

Big Be

 
Big Be:
Short is down, so Short = -1 is effortless to remember.

When there is a choice, the intuitive choice makes life easier!

Big Be

I agree 100%!!

If it is NOT intuitive, then the design needs some work.

 

Personally, I'm indifferent to whether short is -1, 2, 42, -377, whatever...

Because when I code I don't code to the actual integer, I code against the macro. So:

if(mySignal == DIRECTION_SHORT)

{

do stuff...

}

That said, I like to use negative numbers for errors, and I'm agnostic as to whether shorting a currency is a bad thing or not...so it's not intuitive to me either way really (I've made a lot of money shorting currencies ).

Anyway, it really doesn't matter to me.

BW

 
bwilhite:
Personally, I'm indifferent to whether short is -1, 2, 42, -377, whatever...

Because when I code I don't code to the actual integer, I code against the macro. So:

if(mySignal == DIRECTION_SHORT)

{

do stuff...

}

That said, I like to use negative numbers for errors, and I'm agnostic as to whether shorting a currency is a bad thing or not...so it's not intuitive to me either way really (I've made a lot of money shorting currencies ).

Anyway, it really doesn't matter to me.

BW

Right!

That makes the code more flexible which is exactly what I did.

However, with standards there is even more flexibility!

 
TheRumpledOne:
Right!

That makes the code more flexible which is exactly what I did.

However, with standards there is even more flexibility!

Don't know if you'd be interested or not, but you may want to see the new thread I started in this same forum....

On another note...here's something that I have found very helpful:

Most basic trading strategies can be coded as a state machine. For example, anything where you've got "indicator x, y, and z should be in this configuration before doing..." is usually an ideal candidate. So I've got several standard states that I use, such as:

#define STATE_FLAT 0

#define STATE_OPENING_LONG 1

#define STATE_OPENING_SHORT 2

#define STATE_LONG 3

#define STATE_SHORT 4

//other states....

I also wrote a semi-generic state machine to handle these kinds of strategies, and with some work I will make it even more generic. My goal is to get it to the point where the coder is just writing the basic triggers, configuring the state machine, and the state machine takes care of all the opening/closing/stop-loss management, etc. I'm really not too far from this right now, it's just a matter of putting in the few days' time necessary to get it done right. I even think that it would be possible to write a code-generator to enable the super-easy creation of these state machines. I also have a project I started in C# that provides one of the major building-blocks for such a tool.

BW

 

Yes, you are right.

Trading is a STATE MACHINE.

WAIT - ENTER - HOLD - EXIT - WAIT .....

 

A Better Way To Code III

"EVERYTHING THAT CAN BE AN INPUT SHOULD BE AN INPUT"

First, it gives more power to the user.

Second, many user change requests can be avoided by having inputs.

Today, I modified an indicator created by someone else.

My first modification was to make PERIOD an input.

My second modification was to make the multiplier values an input.

My third modification was to make the period part of the object name so multiple instances of the indicator can be loaded.

It's not a big difference coding EXTERN INT rather than just INT but it can make a big difference to the user. It makes the code so much more flexible when all the values are "soft coded" as inputs rather than "hard coded" as constants.

New comment
Reason: