Is there a Limit on Nesting Included Files?
Hello FXtrader2008
Since new code and assume doing incremental compiles as you add code - what makes you think compiler is dodgy?
Does it produce error o/p?
.
New designs and code are notoriously unreliable - that's why new!
.
Have you actually tested all those include files' code? (is it even possible to test these 'black boxes' and if not, why not?)
Code hiding needs to be relevant and excuse me for saying this, but just because you cannot understand some conditional nesting... that is not legit reason to use include's imho.
Just why... is the code so 'hard going' that not understand it? Simplify, simplify continuously!
.
eg, I have a 1sec memory! - lol, so what? well, I do not write code that takes a computing graduate to understand... I use black box coding - single function, no binding with other code. Easily tested for correctness. Vastly reusable for many code areas and code projects! So, I have many many include files but they reside top level in build structure.
This means I know 100% code works cuz I test it... THEN I forget all about it! Why clutter brain with gunk? I document I/F and now... just like the CT builtins, I just call it and not give a damn how it works as long as I understand that it does what designed to do...
.
What about you naming conventions? and... do you have some which use ALL times?
Many times, people use such abstract identifier names! Why? Is like reading Martian at best. FOR SURE you will get confused with nested if's when the code is not relaying any sound messages as to what the heck is doing. (sometimes think some coders are afraid to hit too many keys too often - lol)
Is personal thing in end. I NEED descriptive identifier names. else I just get lost and waste so much time revisiting code above, attempting to get head around what reading below!
How about comments to say WHY the code is doing xyz ? eg, is obvious that a --> b; BUT why??? This allows you to not be brain surgeon when reading your code!
.
How do you know that the syntax is correct?
Is actually doing what your design states?
Additionally, how can you put hand on heart and swear that design is correct for your desired objectives?
.
Is more difficult when working solo. Do you do design reviews, code walk throughs, play computer and desk check, reviewing of module test results,... all by yourself??
How often are you going to disagree with self??? ;-)
You do above with others and they going to ask QUESTIONS, one or more for sure going to SAY that certain design areas, code syntax,... is total GARBAGE (even if smile at you... U know what they really mean!! )
Do you objectively look at your 'masterpiece' or just go woweee, some cool syntax for sure!
.
okaaaay, drone over - but I reckon above are some things s/w people need to consider.
All of course... imho
.
IF firmly going to continue with masses of include files for stated reasons, then somehow YOU must be clear in own head that the compiler is not messin you about, yes?
how?, you can easily generate tons of files, each with a Print() or variable++ or whatever turns you on, to let the included file TELL you that: Yep... I was included!
.
Is certainly not going to solve all other issues which new design and code throws at you but will remove one small item off your TODO list.
.
Regards
Hello FXtrader2008
Since new code and assume doing incremental compiles as you add code - what makes you think compiler is dodgy?
Does it produce error o/p?
.
New designs and code are notoriously unreliable - that's why new!
.
Have you actually tested all those include files' code? (is it even possible to test these 'black boxes' and if not, why not?)
Code hiding needs to be relevant and excuse me for saying this, but just because you cannot understand some conditional nesting... that is not legit reason to use include's imho.
Just why... is the code so 'hard going' that not understand it? Simplify, simplify continuously!
.
eg, I have a 1sec memory! - lol, so what? well, I do not write code that takes a computing graduate to understand... I use black box coding - single function, no binding with other code. Easily tested for correctness. Vastly reusable for many code areas and code projects! So, I have many many include files but they reside top level in build structure.
This means I know 100% code works cuz I test it... THEN I forget all about it! Why clutter brain with gunk? I document I/F and now... just like the CT builtins, I just call it and not give a damn how it works as long as I understand that it does what designed to do...
.
What about you naming conventions? and... do you have some which use ALL times?
Many times, people use such abstract identifier names! Why? Is like reading Martian at best. FOR SURE you will get confused with nested if's when the code is not relaying any sound messages as to what the heck is doing. (sometimes think some coders are afraid to hit too many keys too often - lol)
Is personal thing in end. I NEED descriptive identifier names. else I just get lost and waste so much time revisiting code above, attempting to get head around what reading below!
How about comments to say WHY the code is doing xyz ? eg, is obvious that a --> b; BUT why??? This allows you to not be brain surgeon when reading your code!
.
How do you know that the syntax is correct?
Is actually doing what your design states?
Additionally, how can you put hand on heart and swear that design is correct for your desired objectives?
.
Is more difficult when working solo. Do you do design reviews, code walk throughs, play computer and desk check, reviewing of module test results,... all by yourself??
How often are you going to disagree with self??? ;-)
You do above with others and they going to ask QUESTIONS, one or more for sure going to SAY that certain design areas, code syntax,... is total GARBAGE (even if smile at you... U know what they really mean!! )
Do you objectively look at your 'masterpiece' or just go woweee, some cool syntax for sure!
.
okaaaay, drone over - but I reckon above are some things s/w people need to consider.
All of course... imho
.
IF firmly going to continue with masses of include files for stated reasons, then somehow YOU must be clear in own head that the compiler is not messin you about, yes?
how?, you can easily generate tons of files, each with a Print() or variable++ or whatever turns you on, to let the included file TELL you that: Yep... I was included!
.
Is certainly not going to solve all other issues which new design and code throws at you but will remove one small item off your TODO list.
.
Regards
fby, thank you for the extensive feedback. I appreciate all of your comments. Clearly I took an amateur's approach to using Included Files by adopting that programming technique for the wrong reason. Two years ago when I first encountered the MQ4 language the nested "IF" statements were my undoing and I abandoned the notion of developing an EA. However, earlier this year I recommitted myself to developing an EA and in doing so I concluded Included Files would be an easy way to avoid the complexity of nested code. That aspect actually worked quite well in terms of keeping myself organized.
It occurred to me late last week that I could solve my nesting nightmare by simply substituting the "Included File" callout with the code from the Included File in the place where the callout appears in the EA. The downside, of course, is if I find a logic error in those substitution areas that I will have to correct it in several locations instead of just one location if I am able to leave the code in the Included File.
With respect to your question as to whether the code actually works, I do not know yet. I hope to start testing the EA this week and see if it is processing the incoming info as intended. I have tested many parts of the EA as I develop those parts, but I have not tested the entire EA when all of the modules tied together.
I learned computer programming 30 years ago using FORTRAN. In that language you can use "Go To" statements to route execution control, so it was a real challenge for me to master the execution control aspect in MQ4 with these complex nested routines.
I agree with your "simplify, simplify, simplify" comment. I do not have complex looking flowcharts. If you saw my flowcharts, you would see a vertical list of "IF" statement coming down the page. I try to craft the question in a manner so if the question is yes or no, it results in the execution of simple operators, instead of another "IF" statement in the operator blocks. But, of course there occasions where you cannot avoid another IF statement after you have branched. It is at those locations where I elected to use an Included File to keep me organized and keep the flowchart simple in appearance. Unfortunately, the branching lead to too many tiers, and it does not look like the compiler recognizes the deeply nested Included Files. I know the code that calls each Included File functions, because I tested that aspect before I moved on to the next coding task. However, when I assembled a part of the EA that should call several deeply nested Included Files, the compiler only wanted Included File names going two tiers deep into the EA. At this point I have to assume the EA will not call deeply seated Included Files.
I'm hoping someone actually knows the answer to my original question ----I fear I already know the answer, but it would be nice to know differently ---- Is there a limit on nesting included files?
Thanks again for the extensive feedback fby; it gives me much to ponder as I continue to learn how to program an EA in MQ4.
Best regards,
Hello FXT, nice to hear back!
Remember Hollerith? + ibm punch card m/c's + punched paper tape + ... I btr stop or i be called old - lol
Nearly my first love affair was Fortran. Oh yes... late 60's + Univ of London Atlas Computing Centre @ Russell Sq. 100% L.O.V.E. and once bitten forever smitten!
Bet that's why you just HAD to recharge the batts, clean up the contacts and crank 'er up, yes?
GOOD
ya - GOTO's. Was there for many years. But! HLL's without such syntax are great!
In a way, continue, break mimic the thinking of GOTO. As is having return all over the place. I used to have/educated up to use vip modular design with one entry and one exit philosophy. That requires status flag etc. Then, loosened up a bit and now use return,continue,break instead of using logic all the time. Can be sloppy/confusing so i feel is dbl edged sword to be used/abused in a considered manner.
.
Ah... is this perhaps what you do? not know unless saw code, but prior to my hahaaa, relaxed coding style, the code used only flags and conditional statements to do/not do blocks of code etc.
Perhaps this is the confusion? I only say cuz when I started to rebel against my institutionalised strict methods (becoming lazy ;), I found it massively hard to revert back to the strict coding paradigm which had been drilled into me and not easy to forget!
.
What about... your conditionals ---> functions() that way you retain your good idea of one place to mod only, using includes.
A thot - I use many many convienence functions like that. Ya know? like the simple CT builtins under the Checkup section of ED. docs, eg, IsStopped, IsTesting,...
You could do maybe do same? they are mostly type bool. I even have some tri-state functions that emulate hacked ver of computed goto. Not remember exactly but idea of three state instead of two state boolean, so <|=|> can be returned. I use #defines so called and callers all remain squeaky clean!
oh yes - #defines are great items for set once, use many. I never ever use constants if can avoid it, rather key in a meaningful name instead and anyway! is sooo easy to change once and the who shooting match just follows along following new compile!
.
Remember how switch() works too, this may help. Case values are constants only but they are rather interesting in that you can let cases fall through into some generalised code which all previous cases require doing. Another form of if,then,else in a way.
.
Sorry... is off topic, excuse me.
.
Your include issue I actually not know, I use many includes but, nesting depth is not great: sometimes a includes b which includes c. That's I think!, my limit of use...
Oh heck... just hit me. You know that conceptually, includes are just straight compiler source input redirection and when hits EOF, just remaps up the tree/ next statement and ploughs onwards...
Well, IF you were keen, You could easily code up a preprocessor which takes top level module and let's rip... it's single .mql4 o/p file is then presented to compiler.
hahaaa, all good fun
Regards
fby, thank you for the extensive feedback. I appreciate all of your comments. Clearly I took an amateur's approach to using Included Files by adopting that programming technique for the wrong reason. Two years ago when I first encountered the MQ4 language the nested "IF" statements were my undoing and I abandoned the notion of developing an EA. However, earlier this year I recommitted myself to developing an EA and in doing so I concluded Included Files would be an easy way to avoid the complexity of nested code. That aspect actually worked quite well in terms of keeping myself organized.
It occurred to me late last week that I could solve my nesting nightmare by simply substituting the "Included File" callout with the code from the Included File in the place where the callout appears in the EA. The downside, of course, is if I find a logic error in those substitution areas that I will have to correct it in several locations instead of just one location if I am able to leave the code in the Included File.
With respect to your question as to whether the code actually works, I do not know yet. I hope to start testing the EA this week and see if it is processing the incoming info as intended. I have tested many parts of the EA as I develop those parts, but I have not tested the entire EA when all of the modules tied together.
I learned computer programming 30 years ago using FORTRAN. In that language you can use "Go To" statements to route execution control, so it was a real challenge for me to master the execution control aspect in MQ4 with these complex nested routines.
I agree with your "simplify, simplify, simplify" comment. I do not have complex looking flowcharts. If you saw my flowcharts, you would see a vertical list of "IF" statement coming down the page. I try to craft the question in a manner so if the question is yes or no, it results in the execution of simple operators, instead of another "IF" statement in the operator blocks. But, of course there occasions where you cannot avoid another IF statement after you have branched. It is at those locations where I elected to use an Included File to keep me organized and keep the flowchart simple in appearance. Unfortunately, the branching lead to too many tiers, and it does not look like the compiler recognizes the deeply nested Included Files. I know the code that calls each Included File functions, because I tested that aspect before I moved on to the next coding task. However, when I assembled a part of the EA that should call several deeply nested Included Files, the compiler only wanted Included File names going two tiers deep into the EA. At this point I have to assume the EA will not call deeply seated Included Files.
I'm hoping someone actually knows the answer to my original question ----I fear I already know the answer, but it would be nice to know differently ---- Is there a limit on nesting included files?
Thanks again for the extensive feedback fby; it gives me much to ponder as I continue to learn how to program an EA in MQ4.
Best regards,
fby, thanks again for the feedback. I appreciate the time you have devoted to this topic. I mapped out the Included Files a few days ago to get a nice overview of where they are called in the EA. The map is color coded and provides a nice easy graphic to understand the overview of the situation.
I'm going to take your early advice and cut down on the use of the Included Files. It looks like I can easily reduce the number of Included Files and cut it back to only two tiers (ie where A includes B) without sacrificing too much in terms of repeating code in multiple locations.
I do not understand the "preprocessor" concept contained in your second response; it sounds efficient, but it also sounds beyond my limited programming skills, so we'll set that aside for another day. No need for you to spend all your time on my issue. There are do-able solutions within my grasp and I will proceed with those.
I appreciate your feedback,
Best regards,
fby, thanks again for the feedback. I appreciate the time you have devoted to this topic. I mapped out the Included Files a few days ago to get a nice overview of where they are called in the EA. The map is color coded and provides a nice easy graphic to understand the overview of the situation.
I'm going to take your early advice and cut down on the use of the Included Files. It looks like I can easily reduce the number of Included Files and cut it back to only two tiers (ie where A includes B) without sacrificing too much in terms of repeating code in multiple locations.
I do not understand the "preprocessor" concept contained in your second response; it sounds efficient, but it also sounds beyond my limited programming skills, so we'll set that aside for another day. No need for you to spend all your time on my issue. There are do-able solutions within my grasp and I will proceed with those.
I appreciate your feedback,
Best regards,
FXT - you respond in kind... that is what I only occasionally get. What is frustrating is that chit chat goes on and then like a knife cut, the thread just stops! For sure, all great things come to an end... and this is understood, but what I'm getting at is that many just hit 'n run.
I post not just to give but also to learn too and when the poster(s) just dematerialise without actually stating the 'final solution' it is for me frustrating. Yep, must be a big boy but nevertheless, some topics are really [in my eyes] important yet they just wind up and no one is the wiser!
The expendature of engeries in a thread can be massive sometimes... the conversion of said energies to usable applications (ie, that final solution post) is trivial in comparison. Such a waste imho.
So...!
Real great that you are progressing! Am sure you will enjoy having less include files around (remember possibilities of using little single purpose (and simple) helper() functions)
IF can ever be of use to you, say as wall to bounce off ideas or just want to let me peek at stuff and then hear my comments by return, well just PM - anytime.
Keep me up-to-date on how progressing, ok?
.
Regards
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
I have found nesting conditional "IF" statements to be confusing and prone to numerous errors, hence intimidating, especially when you start nesting 5 or 6 conditional "IF" statements --- one within the next.
As result, I have resorted to using "Included Files" whenever confronted with the nesting challenge. Now after nearly two months of flowcharting and coding my program I am having doubts as to whether the compiler is picking up all of the Included Files that are deeply nested.
It appears the compiler only picks up the 1st tier and 2nd tier Included Files. I say that because I have many more Included Files to be compiled into the program and yet I do not get an error message indicating that I left out file names for Included Files that are in the 3rd, 4th, 5th, and 6th tiers.
Does anyone know if the compiler ignores Included Files beyond the 2nd tier?