Indentation

Belias

Hi everyone,
in your opinion, what's the correct way to indent such code? :-k

IF CONFIRM(STRSUBSTNO(TXCAlreadyExist,FIELDCAPTION("Serial No. Summary"),TBAUHeader.tablecaption,TBAUSerNo."au no.")) THEN EXIT

and here's what i've done (for your better understanding, i substituted the spaces with '*'):

IF CONFIRM(
*****STRSUBSTNO(
*******TXCAlreadyExist,FIELDCAPTION("Serial No. Summary"),TBAUHeader.tablecaption,TBAUSerNo."au no.")) 
THEN
**EXIT

matteo_montanari

Belias wrote:

Hi everyone,
in your opinion, what's the correct way to indent such code? :-k

IF CONFIRM(STRSUBSTNO(TXCAlreadyExist,FIELDCAPTION("Serial No. Summary"),TBAUHeader.tablecaption,TBAUSerNo."au no.")) THEN EXIT

and here's what i've done (for your better understanding, i substituted the spaces with '*'):

IF CONFIRM(
*****STRSUBSTNO(
*******TXCAlreadyExist,FIELDCAPTION("Serial No. Summary"),TBAUHeader.tablecaption,TBAUSerNo."au no.")) 
THEN
**EXIT

Hi

I prefer:

IF CONFIRM(STRSUBSTNO(TXCAlreadyExist,FIELDCAPTION("Serial No. Summary"),TBAUHeader.tablecaption,TBAUSerNo."au no.")) THEN 
  EXIT

or, if there are more parameters:

IF CONFIRM(STRSUBSTNO(TXCAlreadyExist,FIELDCAPTION("Serial No. Summary"),
                      TBAUHeader.tablecaption,TBAUSerNo."au no.")) THEN
  EXIT

bye

Matteo

Belias

Thanks for the instant reply
well, i found this example on "C/AL programming guide", so i was wondering if the same applies for "nested functions" or only for the "not" parameter :-k

IF NOT 
*****SETCURRENTKEY
*******( aaaaaaaaaa,bbbbbbbbbb,cccccccccc, dddddddddd,eeeeeeeeee) 
THEN 
**SETCURRENTKEY(bbbbbbbbbb,aaaaaaaaaa);

matteo_montanari

Belias wrote:

Thanks for the instant reply
well, i found this example on "C/AL programming guide", so i was wondering if the same applies for "nested functions" or only for the "not" parameter :-k

IF NOT 
*****SETCURRENTKEY
*******( aaaaaaaaaa,bbbbbbbbbb,cccccccccc, dddddddddd,eeeeeeeeee) 
THEN 
**SETCURRENTKEY(bbbbbbbbbb,aaaaaaaaaa);

i don't like it

I prefer:

IF [NOT] (Condition [AND/OR] Condition [AND/OR]
          Condition [AND/OR] Condition [AND/OR]) THEN BEGIN
  // Code
  // Code
  // Code
END ELSE
  // Code

or

IF NOT Table.SETCURRENTKEY(Field1, Field2, Field3, Field4, Field5,
                           Field6, Field7, Field8) THEN
  Table.SETCURRENTKEY(Field2, Field1);

Bye

Matteo

kine

Same for me, but somewhere in some document I have seen this style of indentation of parameters:

SETCURRENTKEY( 
**************aaaaaaaaaa,
**************bbbbbbbbbb,
**************cccccccccc, 
**************dddddddddd,
**************eeeeeeeeee);

or something similar... which is good if you have many parameters (you can write comments to each one etc.)

DenSter

When the IF statement spans multiple lines, I like to put the THEN at the same indentation level as the original IF, just to explicitly mark where the condition starts and ends, as a visual clue.

I would not do it like this:

IF [NOT] (Condition [AND/OR] Condition [AND/OR]
          Condition [AND/OR] Condition [AND/OR]) THEN BEGIN
  // Code
  // Code
  // Code
END ELSE
  // Code

Also, I've made it a habit to always use BEGIN and END. With one-liners it looks a little like overkill, but this way I never have to think about whether it's needed, or worry about whether the second line is supposed to be included or not. It makes it easier for me to read/write code.

So I would do it like this:

IF [NOT] (Condition [AND/OR] Condition [AND/OR]
          Condition [AND/OR] Condition [AND/OR]) 
THEN BEGIN
  // Code
  // Code
  // Code
END ELSE BEGIN
  // Code
END;

Plus I would probably also think about keeping just one condition per line:

IF ([NOT] Condition) [AND/OR] 
   ([NOT] Condition) [AND/OR]
   ([NOT] Condition) 
THEN BEGIN
  // Code
END ELSE BEGIN
  // Code
END;

mohana_cse06

I prefer

IF CONFIRM(
**STRSUBSTNO(
****TXCAlreadyExist,
****FIELDCAPTION("Serial No. Summary"),
****TBAUHeader.tablecaption,
****TBAUSerNo."au no."))
THEN 
**EXIT

kriki

There are so many possibilities and there is no one bad or good (at best they are : "not so good" and "better").

The important thing is to define a "house-rule" and stick with it (and change it only when you find out it can be better for some reason. An example.

SETCURRENTKEY(
**"Field 1",
**"Field 2",
**"Field 3",
**"Field 4",
**"Field 5");
It is better
SETCURRENTKEY("Field 1","Field 2","Field 3","Field 4","Field 5");
or
SETCURRENTKEY(
"Field 1","Field 2","Field 3","Field 4","Field 5");

The reason is for searching where an index is used. This way, you can export the objects as text and search for <"Field 1","Field 2","Field 3"> and find the SETCURRENTKEY.

For indenting, there is a rule for NAV (at least there was until all code had to be written in English, but I find the rule still useful):

W1 code:
PostSomeInfo(
***********"Param 1"
***********"Param 2");

IT code:
RegistraQualcheInfo(
***********"Param 1"
***********"Param 2");

The result is that the indentation is off: the parameters are not in the column that comes just after "(".
So the correct way would be the indent by to columns:

W1 code:
PostSomeInfo(
**"Param 1"
**"Param 2");

IT code:
RegistraQualcheInfo(
**"Param 1"
**"Param 2");

Belias

DenSter wrote:

When the IF statement spans multiple lines, I like to put the THEN at the same indentation level as the original IF,

Me, too...but that document (and codeunit 80, too) says that we should indent with the then(begin) on a new line, if the "if" statement spans on multiple lines.
I've also had the habit to always use he begin/end statements (for the same reasons of denster and for the breakpoints placements, too) but in the end i felt tired to see a ton of "END;" at the end of my code... :-k
I think, as you also do, that indentation is (still) too subjective in some cases...it would be easier without the max-characters-per-line limitation :whistle: ...until that day, i think that we have to solve these cases following this rule!

Kriki wrote:

The important thing is to define a "house-rule" and stick with it

Andwian

Belias wrote:

I've also had the habit to always use he begin/end statements (for the same reasons of denster and for the breakpoints placements, too) but in the end i felt tired to see a ton of "END;" at the end of my code...

I agree with you. In one side, it has a plus point, but the drawback is that we will have a tons of BEGIN and END, which in turn will be frustating

DenSter

I don't think that is frustrating at all, I think it makes the code very clear to read.

vaprog

I think leaving out the BEGIN ... END if it only contains a simple statement makes the code more easy to read.
I personally use BEGIN ... END whenever the statement is a complex one (i.e a loop or branch)

I also usualy break indentation rules in some cases, where we use the available language constructs to emulate missing ones. e.g. I use

IF Condition1 THEN BEGIN
  Statement1;
END ELSE IF Condition2 THEN BEGIN
  Statement2;
END ELSE BEGIN
  Statement3;
END;

rather than

IF Condition1 THEN BEGIN
  Statement1;
END ELSE BEGIN
  IF Condition2 THEN BEGIN
    Statement2;
  END ELSE BEGIN
    Statement3;
  END;
END;

emulating an if ... then ... elsif ... else structure
and

IF FINDFIRST THEN REPEAT
  Statement;
UNTIL NEXT = 0;

rather than

IF FINDFIRST THEN BEGIN
  REPEAT
    Statment;
  UNTIL NEXT = 0;
END;

(With or without BEGIN END for the THEN part) emulating a foreach REC do.

Belias

1st: please use findSET instead of findFIRST when you're looping records
2nd: i keep on using "useless" begin end when there are more than one line of code, because it makes it easier to understand (but as always, this is a personal opinion)
e.g.:

IF a = 1 THEN BEGIN
  IF b = 1 THEN
    ItemLedgEntry.DELETEALL;
END;

althought we should use

IF a = 1 THEN
  IF b = 1 THEN
    ItemLedgEntry.DELETEALL;

P.S.: do not run the code i wrote (unless you set "a" or "b" to be <> 1)

Andwian

Belias wrote:

P.S.: do not run the code i wrote (unless you set "a" or "b" to be <> 1)

Whoa! What a harm code to test.