Van Vugt: Some Compounds Statements - Part 2 - Dynamics CRM: Blogs

Blog bot · 03.08.2013, 10:22

So where should compound statement be inserted in the samples I posted this week to get the code work right? Have a look below.

But first ...
... code can work technically right when it compiles and doesn't throw any run-time error, which is a minimum of any code IMHO. For sure it's not the full monty as it also should work right from a functional perspective. Of course the code samples are only snippets without the broader picture, but it wasn't that difficult to the at least have deducted some context. As you might have guessed the snippets hadn't been made up and were taken from standard NAV 2013 from which I removed the BEGIN's and END's. And ... for lay-out purposes I renamed some variables.

Sample 1 - Codeunit 99008502 (Sales Order-Accept)
Technically this snippet can do without. However, for functional purposes we do need BEGIN-END.

Hooray for both respondents!

Just a nitty gritty comment: jglathe's suggestion does not (fully) comply to the C/AL coding standards: When BEGIN follows THEN, ELSE, or DO, it should be on the same line and preceded by one space character.

1. SalesCommentLine.SETRANGE("Document Type",SalesQHeader."Document Type");
2. SalesCommentLine.SETRANGE("No.",SalesQHeader."No.");
3. WHILE SalesCommentLine.FIND('-') DO BEGIN
4. SalesCommentLine.DELETE;
5. SalesCommentLine."Document Type" := SalesOrderHeader."Document Type";
6. SalesCommentLine."No." := SalesOrderHeader."No.";
7. SalesCommentLine.INSERT;
8. END;
Sample 2 - Codeunit 6 (Fiscal Year-Close)
To get this code compiled BEGIN-END is mandatory as it will throw the well known compile error, because of an incorrect (or incomplete) IF-THEN-ELSE construction:

Hooray for both respondents!

And for the same reason as above jglathe's suggestion does not (fully) comply to the C/AL coding standards.

1. IF AccountingPer2.FIND('>') THEN BEGIN
2. FiscalYearEndDate := CALCDATE('<-1D>',AccountingPer2."Starting Date");
3. AccountingPer3 := AccountingPer2;
4. AccountingPer2.SETRANGE("New Fiscal Year");
5. AccountingPer2.FIND('<')
6. END ELSE
7. ERROR(Text001);
Note
In codeunit 6 there is purposeless empty line between line 2 and 3.

Sample 3 - Page 5128 (Close Opportunity)
To get this code compiled BEGIN-END is mandatory as it will throw a compile error, because of an seemingly incorrect option SalesQuoteEnable := FALSE:

Hooray for both respondents!

However, now AntidotE's suggestion does not (fully) comply to the C/AL coding standards for CASE Statament: If there is a BEGIN, then it should be put on a separate line unless it follows ELSE.

1. CASE "Action Taken" OF
2. "Action Taken"::Won:
3. IF Opp.GET("Opportunity No.") THEN
4. SalesQuoteEnable := Opp."Sales Document No." <> '';
5. "Action Taken"::Lost:
5.5. BEGIN
6. CalcdCurrentValueLCYEnable := FALSE;
7. SalesQuoteEnable := FALSE;
7.5. END;
8. END;
Sample 4 - Codeunit 422 (XBRL Import Taxonomy Spec. 2)
Both technically and functionally this snippet can do without! But C/AL coding standards prescribe the use of BEGIN-END as per below.

Hooray for jglathe!

1. CASE LOWERCASE("XBRL Item Type") OF
2. 'stringitemtype','string':
3. "Source Type" := "Source Type":

escription;
4. 'monetaryitemtype':
5. "Source Type" := "Source Type"::"General Ledger";
6. 'decimalitemtype':
7. "Source Type" := "Source Type"::Constant;
8. 'sharesitemtype' :
9. "Source Type" := "Source Type"::Constant;
10. 'uriitemtype':
11. "Source Type" := "Source Type":

escription;
12. 'tupletype':
13. "Source Type" := "Source Type"::Tuple;
14. ELSE BEGIN
15. "Source Type" := "Source Type"::"Not Applicable";
16. IF "XBRL Item Type" <> '' THEN
17. Description := STRSUBSTNO(Text007,"XBRL Item Type");
17.5. END;
18. END;
Note
For clarity purpose I had removed the last case option as I wanted to have focus on the ELSE part.

Sample 5 - Codeunit 213 (Res. Jnl.-Post Batch)
This snippet is taken form the local function CheckRecurringLine. Actually this is all the code this function is holding so both technically and functionally no need for BEGIN-END.

Hooray for both respondents!

However standard NAV 2013 holds BEGIN-END as per the below, which, IMHO, is not in accordance with C/AL coding standards as it is redundant (see also Redundant BEGIN ... END).

1. WITH ResJnlLine2 DO BEGIN
2. IF "Resource No." <> '' THEN
3. IF ResJnlTemplate.Recurring THEN BEGIN
4. TESTFIELD("Recurring Method");
5. TESTFIELD("Recurring Frequency");
6. IF "Recurring Method" = "Recurring Method"::Variable THEN
7. TESTFIELD(Quantity);
8. END ELSE BEGIN
9. TESTFIELD("Recurring Method",0);
10. TESTFIELD("Recurring Frequency","0DF");
11. END;
12. END;
References