LibreOffice Code Conventions
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
Code Conventions
Most of the LibreOffice code is written with C++, but there are also many source code files that are in Java, Python and BASIC. LibreOffice uses specific coding conventions, in naming, data type and many other things. Following those conventions helps keeping the code clean and readable.
LibreOffice Data Types
The data types that are listed in the following table are used for members of structs, as method return types or method parameters. Also, mappings to Java, C++, and LibreOffice Basic types are provided.
| UNO | Type description | Java | C++ | Basic |
|---|---|---|---|---|
| void | empty type, used only as method return type and in any |
void | void | - |
| boolean | Boolean type; true and false | boolean | bool (sal_Bool is deprecated) |
Boolean |
| byte | signed 8-bit integer type | byte | sal_Int8 | Integer |
| short | signed 16-bit integer type | short | sal_Int16 | Integer |
| unsigned short | unsigned 16-bit integer type (deprecated) | - | sal_uInt16 | - |
| long | signed 32-bit integer type | int | sal_Int32 | Long |
| unsigned long | unsigned 32-bit integer type (deprecated) | - | sal_uInt32 | - |
| hyper | signed 64-bit integer type | long | sal_Int64 | - |
| unsigned hyper | unsigned 64-bit integer type (deprecated) | - | sal_uInt64 | - |
| float | IEC 60559 single precision floating point type | float | float (if appropriate) | Single |
| double | IEC 60559 double precision floating point type | double | double (if appropriate) | Double |
| char | 16-bit Unicode character type (more precisely: UTF-16 code units)- | char | sal_Unicode | - |
| string[1] | Unicode string type (more precisely: strings of Unicode scalar values) | java.lang.String | rtl::OUString | String |
C++ Code Conventions
LibreOffice uses C++ 20 as the standard for the code base. Therefore, you can use the latest features that are available in C++20.
On the other hand, there are things that are specific to LibreOffice source code. In order to make it possible to have interoperability across different operating systems and different programming languages for the LibreOffice API, LibreOffice has its own set of data types, as discussed above.
Code Formatting
For the newer files, you should use the tool clang-format, to re-format your code. Otherwise, CI will not accept your submitted code.
Naming Conventions
In LibreOffice C++ code, there are specific rules for naming variables according to their data types. That is helpful to learn about the data type of a variable by just looking into its prefix.
| Data Type | Template | Example |
|---|---|---|
| (Smart) pointer/reference to a UNO interface | xName | xContext
|
| (Smart) pointer to anything else | pName | pControl
|
| Reference to anything else | rName | rTopic
|
| Integer value | nName | nWhich
|
| Floating-point number | fName | fWidth
|
| Boolean | bName, or isName, or canName | isEndOfSentence
|
| String | optionally sName (for char * -> pName; for OUString -> aName | sDateFormat |
| Another object | aName | aActual |
Header Includes
For including headers, this style is used:
- First include, should be always
<sal/config.h> - Then, other includes come into groups, separated by 1 blank line, and sorted lexicographical inside each group:
- Standard includes (e.g.
<memory>) - Current module-local includes
- Includes from
$SOURCE_FOLDER/include(e.g.,<osl/...>,<vcl/...>) - UNO interface includes (e.g.
<com/sun/star/...>)
- Standard includes (e.g.
Please note that sometimes the groups come in other orders.
Use the "..." form if and only if the included file is found next to the including file. Otherwise, use the <...> form. [2]
The UNO API include files should consistently use double quotes, for the benefit of external users of this API. This is used inside UNO API include files, and not elsewhere where they are used with UNO interface.
Python Code Conventions
Would be great if you observe for the Python code in LibreOffice (all rules here are from PEP-8):
Indentation
Use 4 spaces per indentation level. Do not mix tabs and spaces.
Line Length
Limit all lines to a maximum of 99 characters. For docstrings/comments, limit to 92 characters.
Naming Conventions
- snake_case for variables, functions, and modules (e.g., my_variable, calculate_total()).
- CamelCase for classes (e.g., MyClass).
- UPPER_CASE for constants (e.g., MAX_OVERFLOW).
Spacing
- Put one space around operators (=, +, -, ==, etc.) and after commas.
- No space immediately inside parentheses, brackets, or braces: spam(ham[1]).
Imports
- Imports should be on separate lines.
- Group them in this order:
- Standard library imports.
- Related third-party imports.
- Local application/library specific imports.
Whitespace
- Surround top-level function and class definitions with one blank lines.
- Method definitions inside a class are surrounded by one blank line.
Notes
- ↑ There are special conditions for types that do not have an exact mapping in this table. Check for details about these types in the corresponding sections about type mappings in UNO Language Bindings
- ↑ For further details, see the mail Re: C[++]: Normalizing include syntax ("" vs <>).
External Links
LibreOffice inherits code from OpenOffice.org. These are the related code convention pages: