bloops/cockups

[stimpy]

I was talking about coding today - its a funny old thing.
Today I realised i was pulling in the wrong buffers on 2 different indicators and have been running tests on the wrong basis since October - whoops.

Don't know why today I should find those errors....

Maybe I need to get a bit more formal in my coding?

[garyfritz]

It's very easy to toss together some code. Often it even appears to work. But without some care in the design and in checking/verifying the code and the results, you may find it's not doing what you thought it was. Tossed-together code also tends to be extremely hard to understand (even by you, a few weeks from now) or to change.

That might be OK if it's a one-off for experimentation purposes. But if you're writing something that you expect to use for any period of time, and especially if you plan to risk money based on it, it's smart to invest some time and care into producing quality and reliable code. Get somebody you trust to review it so you have another set of eyeballs looking for problems.

You wouldn't go auto-racing with a rattletrap jalopy you slapped together over the weekend. Why would you risk your money with the MQL equivalent??

[SteveHopwood]

Hehe. I am your bloop/cockup expert. You ever need advice on how to make them, come to me. I would gain an instant Doctorate in them if such were available. My copy/paste bloops are the stuff of legends.

I am slowly getting better at avoiding them. Here is how:

• When I have to code a fresh function, I move away from the computer and think about what I have to do. It helps when these thought periods correspond with bathtime, but it is not actually essential that my thought periods happen in the bath. Instead, the sofa will do, so I have: bath loll; sofa loll. Most problems I solve are solved during these times.
  
  I comment nearly everything. I have learned from grim and bitter experience this salutary fact: a code snippet whose meaning is so screamingly obvious now that a comment is clearly a ludicrous waste of time, will take me three hours to decipher in 2 months time. Look at squalou's code for magnificent examples of commenting.
  
  When coding an EA, include a description of the trading methodology in an comment somewhere - or at least a link to the post that inspired you to code it. I have not done this in the past. When someone contacts me and asks, "Hi Steve. Can you please add this tiny tweak to xxx EA?", it takes me 2 minutes to add the tweak. After I have spend all day working out what the EA actually does.
  
  When adding code to a function, ask yourself whether this code should be in its own separate function. A classic example of this is how I have recently moved tp/sl calculations in my shell code, from the functions such as LookForTradingOpportunities and HasBuyFilled etc into their own individual functions. Instead of slavishly recreating the same code several times, I can now simply add a call to the CalculateTakeProfit() etc functions. From here, CalculateTakeProfit() can hold several different tp calc methods, and return the one that is actually required.

So, what you describe as being more 'formal' is actually about being more organised now; this will save you hours of disorganisation in the future. Guess how I know?

[SteveHopwood]

Another tip, and a huge one is this: remember Google.

We both know how enigmatically unhelpful some of the mql4 'help' is. Google often provides enlightenment.

To be honest, the only reason I resort to Google is that I do not want to bug our invaluable resource here too much. That invaluable resource? TIG.

George is fantastic, and will always help us when we are stuck. I just prefer not to wimp to him too often.

[stimpy]

Yes I am like that... I have a couple of coder friends who help me out ( to their despair - there are 3 guys over the last few years who have probably turned grey from it) - I am an engineer by trade so the move into coding is interesting.

Commenting is good - i do put comments on stuff to remind me where I am and what things do - I think testing what you have written is where the crux is - i run a visual test on stuff I do - every tick is just so fricking painful i resort to open bar most times...

my only tip after this recent bloop is - print most stuff out on the terminal screen value wise - buffers in one indicator are not necessarily what you may think!

I think most of my bloops come from ramming stuff in, i get ideas and try to work with those ideas in the terminal and make them work in the code - last night I stayed up all night and got it working - when doing things like this you are obviously knackered and mistakes will creep in - but its addictive is that problem solving puzzlement by 'eck.