Tips for beginning Developers

 

I think this would be a goo d way to help new developers. This may even be sticky worthy. There are many neaunces that can trip up a new developer. To smooth the way, I thought it would be a good idea to post some tips to help out.

=======================================================================

Print is your friend - when you write an automation, it is best to send all of your variables to a print command. This way it is always easy to see if you are getting the values you expect to get. Also use a print command with decision trees like if conditions. If this do that, else do something else should have a print statement in each condition and after the decision tree. This way you will always be able to see your way in and through your code.

Print(" Price is: ", Ask);

I like to create a boolean called "debug", I set it to true to see the print statements and false to hide them. Then in the code I use my print statements like this:

// declaration:

bool debug = true;

// Implementation:

if (debug) Print("Price: ", Ask);

A simple one liner that helps me to find a lot of bugs fast.

=======================================================================

Error 130 - This is a common error difficult to track down with many ellusive possibilities. The very first one I would assume is that the broker does not allow stop loss or take profit entries to be performed in the OrderSend command, in this case you need to perform the OrderSend with stop loss and take profit = 0. Then perform a OrderModify which is where I put in the real stop loss and take profit values. Also, it is good to wrap the OrderSend and OrderModify in an if statement to see if an error occurs. On a modification order, you may want to consider looping the order for a few itterations say maybe 5, to ensure your modification took. Check the success or failure in each loop, and allow a time to wait and a refresh of data. If you have not been successful in 5 tries, consider printing out the request values of stop loss and take profit. Compare it to a manual entry of the trade. If the broker has some special limitations, you will see this in the difference of the printed values and the message on the manual trade window. for example, broker may require a minimum of 5 pips between stop loss and Ask, you may think you are using 5 pips, but when you print it out, you find that you are in a 5 digit (ECN) scenario and you actually passed it a .00005 instead of a .00050.

=====================================================================

bracket curly bracket, whose got my curly bracket - this is the most frustrating issue. Trying to figure out why it is telling me that I don't have a correctly terminated curly bracket block of code. A good way to prevent it is to create the statement then the curly brackets (both open and closing) then enter the action statements.

Example:

if (sky == "blue")

{



{

else

{



}

or

int MyCoolFunction()

{




}

If you line the curly brackets up with the statement, you can visually follow your way through the code. Here is how they look after you complete the task:

if (sky == "blue")

{

       // The sky is blue

      print("The sky is blue");

{

else

{

       // The sky is NOT blue

      print("The sky is NOT blue");

}

or

int MyCoolFunction()

{

      // My  code is indented so I re-inforce the visibility of my lining up of brackets

      Print("This is my cool function");
}

=========================================================================

Experienced developers, please join me in this effort to reduce these issues by providing tips here for others. I would even recommend using this location to strut your stuff with some cool tricks that you have made.

 

Other good tips:

.

1. Always keep in mind that not all brokers are 5 digits. In the same way, try to keep compatibility across brokers to a maximum. Helps diversify the testing phases.

2. If Point is 0.001 or 0.00001, point_compat = 10. Otherwise point_compat = 1. Then always just apply this to settings in PIPs when calculating.

3. STOPLEVEL, MINLOT, and MAXLOT are important to check with the MarketInfo() function to avoid very annoying errors that crawl up on you.

4. Comment() also helps a lot when debugging. Can be refreshed at every tick so you know what your EA is doing at all times.

5. When live, the whole world doesn't stop for you to send an order. Always put you OrderSend()'s in a retry loop (3-5 retries is good) *RefreshRates() and renew TP/SL inside that loop*

6. A good error catching function can take 5-10 minutes to do but will save you having to go into the documentation everytime you have an error number.

7. Always normalize your doubles to the number of broker digits to avoid useless errors. Lots always normalized to the MarketInfo(LOTSTEP) amount of digits.

8. Always name your variable to be self-describing. Integers named "x" should only be used for loops. Self describing names will save you a lot of time when re-evaluating your own code later.

9. Keep your code clean! Always open and close your blocks in the same manner to avoid missing squiggly brackets and such.

10. Always have docs.mql4.com open to refer to the manual pages. A glimpse takes a few seconds but writing code and correcting it afterwards can take minutes.

11. To round decimal numbers, add half the point you are normalizing to. (1.7 + 0.5 = 2.2 -> normalized to 0 digits = 2, 1.23 + 0.05 = 1.27 -> normalized to 1 digit = 1.2).

12. Make everything customizable externally to avoid having to change code and recompile before re-running it.

13. Try to use doubles as much as possible instead of ints to avoid starting a condition with an int and losing all decimal places. Start a calculation with a double type if you have an int in there.

14. If something seems illogical or "weird" you are missing something. Code is 100% logic.

15. In every case, you should incorporate error-catching. You don't want to continue normal behaviour if something didn't go through correctly.

.

That's pretty much all that comes to mind at the moment. I'll post back if I think of anything else.

.

Jon

 

I forgot the most important of all:

.

16. Don't start writing code until you have it all planned out (pseudo-code or simple notes -- I mix both). Coding a section then rewriting takes a lot longer than writing notes then correcting. It also usually makes the code a lot more sophisticated when completed since you knew where you were heading when writing it.

.

Jon

Reason: