1. Scilab Coding Style

Some rules to write Scilab macros...These rules will be the basis for Scilab 6.0 pretty printer.

1.1. Scilab 5.x

1.1.1. Character string declaration

Only use double-quotes to define character strings. Simple quotes will only be available in Scilab 6.0 for ascendant compatibility.

mystr = "mystr";

1.1.2. No more use function ''deff'' where ''function''/''end'' can be used

No more use function deff, this function makes the code unreadable and will be removed in a future version. Only use function/end to declare functions. If you need to declare a function with a generated declaration, use execstr.

   1 // This code is OK
   2 function foo()
   3   disp("hello")
   4 end
   5 
   6 // This code is not OK
   7 generatedcode = "disp(""hello"")";
   8 execstr("function toto();" + generatedcode + ";endfunction");

1.1.2.1. Rationale

The use of the "execstr" function makes the scripts very difficult to understand and to maintain. Indeed, adding a new statement in the function forces to manage the double quotes in complicated ways, which leads to bugs.

1.1.3. Matrix declaration

While defining matrices, use commas between row elements and semi-colons between rows.

   1 // This code is OK
   2 mymatrix = [1,2,3;4,5,6];
   3 myothermatrix = [1,2,3; ..
   4                  4,5,6];
   5 
   6 // This code is not OK
   7 mymatrix = [1 2 3
   8             4 5 6];

1.1.4. One statement per line

For code readability, only write one statement per line:

   1 // This code is OK
   2 a = 1;
   3 b = 2;
   4 c = 3;
   5 
   6 // This code is not OK
   7 a = 1;b = 2;c = 3;

1.1.4.1. Rationale

• This makes interactive debug much easier.
• Adding a new statement is more easy (the "bad" method may produce extremely long lines).

1.1.5. Semi-colon at the end of each statement

In a function, each statement must finish with a semi-colon. In a script, the usage of a semi-colon at the end of a line is a mean to manage display of execution results.

   1 // This code is OK
   2 a = 1;
   3 b = 2;
   4 c = 3;
   5 
   6 // This code is not OK
   7 a = 1,
   8 b = 2
   9 c = 3

1.1.6. Loops/Conditions

For code readability, "if" blocks, "for" loops, "while" loops must be written in at least three lines as in :

   1 // This code is OK
   2 if part(XNAME,k)==',' then
   3   index_commas=[index_commas,k];
   4 end
   5 
   6 // This code is not OK
   7 if part(XNAME,k)==',' then index_commas=[index_commas,k],end

1.1.6.1. Rationale

• The code is difficult to manage with an interactive debugger. Indeed, the line is executed as one statement, so that we do not know if the condition was true and the block was executed.
• The code is difficult to understand. There are 3 commas "," in the line, where each one has a different role.
• The code is difficult to maintain. Indeed, if the condition is to be modified, this can lead to bugs, where the condition has been copied and pasted into the executed block instead of the condition block. If the executed block is to be extended with additional statements, the line will be extremely long.

These rules have to be applied inside macros you just modify.

1.2. Scilab 6.0

1.2.1. Function declaration using ''function'' and ''end''

Only use end keyword to close a function declaration (endfunction will only be kept for ascendant compatibility)

1.3. Discussion

• I suggest that the reason of the rules are explained wherever possible (with counter examples if possible). This will stimulate people to use the rules, instead of feeling forced (the "military" way). Practical experience shows that most of programmation rules which are not clearly explained and understood are simply ignored as soon as they are written... This is why I added the "Rationale" paragraph for some rules.