calc: on editing invalidation of view with different zoom is wrong
[LibreOffice.git] / wizards / source / scriptforge / _CodingConventions.xba
blob71fb42c77201d47b86570bfaa30ff3ebe461e3c0
1 <?xml version="1.0" encoding="UTF-8"?>
2 <!DOCTYPE script:module PUBLIC "-//OpenOffice.org//DTD OfficeDocument 1.0//EN" "module.dtd">
3 <script:module xmlns:script="http://openoffice.org/2000/script" script:name="_CodingConventions" script:language="StarBasic" script:moduleType="normal">REM =======================================================================================================================
4 REM === The ScriptForge library and its associated libraries are part of the LibreOffice project. ===
5 REM === Full documentation is available on https://help.libreoffice.org/ ===
6 REM =======================================================================================================================
8 &apos;&apos;&apos;
9 &apos; Conventions used in the coding of the *ScriptForge* library
10 &apos; -----------------------------------------------------------
11 &apos;&apos;&apos;
12 &apos; Library and Modules
13 &apos; ===================
14 &apos; * Module names are all prefixed with &quot;SF_&quot;.
15 &apos; * The *Option Explicit* statement is mandatory in every module.
16 &apos; * The *Option Private Module* statement is recommended in internal modules.
17 &apos; * A standard header presenting the module/class is mandatory
18 &apos; * An end of file (eof) comment line is mandatory
19 &apos; * Every module lists the constants that are related to it and documented as return values, arguments, etc.
20 &apos; They are defined as *Global Const*.
21 &apos; The scope of global constants being limited to one single library, their invocation from user scripts shall be qualified.
22 &apos; * The Basic reserved words are *Proper-Cased*.
23 &apos;&apos;&apos;
24 &apos; Functions and Subroutines
25 &apos; =========================
26 &apos; * LibreOffice ignores the Private/Public attribute in Functions or Subs declarations.
27 &apos; Nevertheless the attribute must be present.
28 &apos; Rules to recognize their scope are:
29 &apos; * Public + name starts with a letter
30 &apos; The Sub/Function belongs to the official ScriptForge API.
31 &apos; As such it may be called from any user script.
32 &apos; * Public + name starts with an underscore &quot;_&quot;
33 &apos; The Sub/Function may be called only from within the ScriptForge library.
34 &apos; As such it MUST NOT be called from another library or from a user script,
35 &apos; as there is no guarantee about the arguments, the semantic or even the existence of that piece of code in a later release.
36 &apos; * Private - The Sub/Function name must start with an underscore &quot;_&quot;.
37 &apos; The Sub/Function may be called only from the module in which it is located.
38 &apos; * Functions and Subroutines belonging to the API (= &quot;standard&quot; functions/Subs) are defined in their module in alphabetical order.
39 &apos; For class modules, all the properties precede the methods which precede the events.
40 &apos; * Functions and Subroutines not belonging to the API are defined in their module in alphabetical order below the standard ones.
41 &apos; * The return value of a function is always declared explicitly.
42 &apos; * The parameters are always declared explicitly even if they&apos;re variants.
43 &apos; * The Function and Sub declarations start at the 1st column of the line.
44 &apos; * The End Function/Sub statement is followed by a comment reminding the name of the containing library.module and of the function or sub.
45 &apos; If the Function/Sub is declared for the first time or modified in a release &gt; initial public release, the actual release number is mentioned as well.
46 &apos;&apos;&apos;
47 &apos; Variable declarations
48 &apos; =====================
49 &apos; * Variable names use only alpha characters, the underscore and digits (no accented characters).
50 &apos; Exceptionally, names of private variables may be embraced with `[` and `]` if `Option Compatible` is present.
51 &apos; * The Global, Dim and Const statements always start in the first column of the line.
52 &apos; * The type (*Dim ... As ...*, *Function ... As ...*) is always declared explicitly, even if the type is Variant.
53 &apos; * Variables are *Proper-Cased*. They are always preceded by a lower-case letter indicating their type.
54 &apos; With next exception: variables i, j, k, l, m and n must be declared as integers or longs.
55 &apos; &gt; b Boolean
56 &apos; &gt; d Date
57 &apos; &gt; v Variant
58 &apos; &gt; o Object
59 &apos; &gt; i Integer
60 &apos; &gt; l Long
61 &apos; &gt; s String
62 &apos; Example:
63 &apos; Dim sValue As String
64 &apos; * Parameters are preceded by the letter *p* which itself precedes the single *typing letter*.
65 &apos; In official methods, to match their published documentation, the *p* and the *typing letter* may be omitted. Like in:
66 &apos; Private Function MyFunction(psValue As String) As Variant
67 &apos; Public Function MyOfficialFunction(Value As String) As Variant
68 &apos; * Global variables in the ScriptForge library are ALL preceded by an underscore &quot;_&quot; as NONE of them should be invoked from outside the library.
69 &apos; * Constant values with a local scope are *Proper-Cased* and preceded by the letters *cst*.
70 &apos; * Constants with a global scope are *UPPER-CASED*.
71 &apos; Example:
72 &apos; Global Const ACONSTANT = &quot;This is a global constant&quot;
73 &apos; Function MyFunction(pocControl As Object, piValue) As Variant
74 &apos; Dim iValue As Integer
75 &apos; Const cstMyConstant = 3
76 &apos;&apos;&apos;
77 &apos; Indentation
78 &apos; ===========
79 &apos; Code shall be indented with TAB characters.
80 &apos;&apos;&apos;
81 &apos; Goto/Gosub
82 &apos; ==========
83 &apos; The *GoSub* … *Return* statement is forbidden.
84 &apos; The *GoTo* statement is forbidden.
85 &apos; However *GoTo* is highly recommended for *error* and *exception* handling.
86 &apos;&apos;&apos;
87 &apos; Comments (english only)
88 &apos; ========
89 &apos; * Every public routine should be documented with a python-like &quot;docstring&quot;:
90 &apos; 1. Role of Sub/Function
91 &apos; 2. List of arguments, mandatory/optional, role
92 &apos; 3. Returned value(s) type and meaning
93 &apos; 4. Examples when useful
94 &apos; 5. Eventual specific exception codes
95 &apos; * The &quot;docstring&quot; comments shall be marked by a triple (single) quote character at the beginning of the line
96 &apos; * Meaningful variables shall be declared one per line. Comment on same line.
97 &apos; * Comments about a code block should be left indented.
98 &apos; If it concerns only the next line, no indent required (may also be put at the end of the line).
99 &apos;&apos;&apos;
100 </script:module>