In Standard Navision 3.60 codeunit 22 is a case of statement: CASE EntryFindMethod OF ‘-’: IF ItemLedgEntry2.NEXT = 0 THEN EXIT; ‘+’: IF ItemLedgEntry2.NEXT(-1) = 0 THEN EXIT; END; Isn’t is so that unless the THEN statement, if the code for one issue here for example the ‘-’ and the ‘+’, is more than 1 line this code should always have a BEGIN and END. Like this: CASE EntryFindMethod OF ‘-’: BEGIN IF ItemLedgEntry2.NEXT = 0 THEN EXIT; END; ‘+’: BEGIN IF ItemLedgEntry2.NEXT(-1) = 0 THEN EXIT; END; END; I run the code with the code coverage and it looks like that he always runs through the last EXIT in the standard code. With the BEGIN and END statements is doesn’t runs the EXIT.
I don’t really know what you are getting at, but IF ItemLedgEntry2.NEXT = 0 THEN EXIT; is considered one statement, so the BEGIN/END are not needed.
Exactly. It is confusing, but is right. If you want your code looks clearer always use IF <cond> THEN BEGIN <one or more statements>; END; Your piece of code: CASE EntryFindMethod OF '-' : BEGIN IF ItemLedgEntry2.NEXT = 0 THEN BEGIN EXIT; END; END; '+' : BEGIN IF ItemLedgEntry2.NEXT(-1) = 0 THEN BEGIN EXIT; END; END; END; Someone would dissagre, but I’ve seen so many times original simple 2 lines IF statement enhanced with a new line, but forgeting to wrap all in BEGIN END…
Robi, For what it’s worth, I tend to agree with you. What’s particularly hard to read is nested if-then-else constructs without begin/ends. However, it really is a matter of style. I believe both styles are readable depending on what you’re used to seeing (and it’s all relative too - try reading some AWK code sometime). IMHO, what improves readability the most is using the same style consistently thoughout your code. When I modify existing Navision code, I try to emulate the existing style even though it often runs counter to my own preferences. I do make one exception to this rule: I comment my code [:)] -Alan
I find that the easiest “style” to read is when people “Line-up” and TABulate their code…e.g. …If THEN …|…BEGIN …|…|…; …|…|…; …|…END …ELSE …BEGIN …|…CASE OF …|…|…‘xx’: …|…|…|…BEGIN …|…|…|…|…; …|…|…|…|…; …|…|…|…END; …|…|…‘yy’: …|…|…BEGIN …|…|…|…; …|…|…|…; …|…|…END: …|…END; …END; hope you get the point![8D]
quote:
Originally posted by RemcovanH
I run the code with the code coverage and it looks like that he always runs through the last EXIT in the standard code. With the BEGIN and END statements is doesn’t runs the EXIT.
I agree that the readability of the code being discussed here leaves a lot to be desired. From Remco’s post, however, it seems that the code is actually working differently, or maybe I didn’t understand well. Is this just a fluke of Code Coverage? If not, how can this be explained or fixed? Thanks, Alastair
Apologies for digressing. Using a code snippet (and debugging on), I tested both CASE statement syntaxes with & without Code Coverage and didn’t see any difference in result. Not exactly a full test: I guess it’s possible something in CU22 specifically messes something up. Best I can do for now.