code_style_guidelines.rst 16 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372
  1. .. _doc_code_style_guidelines:
  2. Code style guidelines
  3. =====================
  4. .. highlight:: shell
  5. When contributing to Godot's source code, you will be expected to follow the
  6. style guidelines outlined below. Some of them are checked via the Continuous
  7. Integration process and reviewers will ask you to fix potential issues, so
  8. best setup your system as outlined below to ensure all your commits follow the
  9. guidelines.
  10. C++ and Objective-C
  11. -------------------
  12. There are no written guidelines, but the code style agreed upon by the
  13. developers is enforced via the `clang-format <https://clang.llvm.org/docs/ClangFormat.html>`__
  14. code beautifier, which takes care for you of all our conventions.
  15. To name a few:
  16. - Indentation and alignment are both tab based (respectively one and two tabs)
  17. - One space around math and assignments operators as well as after commas
  18. - Pointer and reference operators are affixed to the variable identifier, not
  19. to the type name
  20. - See further down regarding header includes
  21. The rules used by clang-format are outlined in the
  22. `.clang-format <https://github.com/godotengine/godot/blob/master/.clang-format>`__
  23. file of the Godot repository.
  24. As long as you ensure that your style matches the surrounding code and that you
  25. not introducing trailing whitespace or space-based indentation, you should be
  26. fine. If you plan to contribute regularly, however, we strongly advise that you
  27. set up clang-format locally to check and automatically fix all your commits.
  28. .. warning:: Godot's code style should *not* be applied to third-party code,
  29. i.e. that is included in Godot's source tree but was not written
  30. specifically for our project. Such code usually comes from
  31. different upstream projects with their own style guides (or lack
  32. thereof), and don't want to introduce differences that would make
  33. syncing with upstream repositories harder.
  34. Third-party code is usually included in the ``thirdparty/`` folder
  35. and can thus easily be excluded from formatting scripts. For the
  36. rare cases where a third-party code snippet needs to be included
  37. directly within a Godot file, you can use
  38. ``/* clang-format off */`` and ``/* clang-format on */`` to tell
  39. clang-format to ignore a chunk of code.
  40. .. seealso::
  41. These guidelines only cover code formatting. See :ref:`doc_cpp_usage_guidelines`
  42. for a list of language features that are permitted in pull requests.
  43. Using clang-format locally
  44. ~~~~~~~~~~~~~~~~~~~~~~~~~~
  45. First of all, you will need to install clang-format. As of now, you need to use
  46. **clang-format 13** to be compatible with Godot's format. Later versions might
  47. be suitable, but previous versions may not support all used options, or format
  48. some things differently, leading to style issues in pull requests.
  49. Installation
  50. ^^^^^^^^^^^^
  51. Here's how to install clang-format:
  52. - Linux: It will usually be available out-of-the-box with the clang toolchain
  53. packaged by your distribution. If your distro version is not the required one,
  54. you can download a pre-compiled version from the
  55. `LLVM website <https://releases.llvm.org/download.html>`__, or if you are on
  56. a Debian derivative, use the `upstream repos <https://apt.llvm.org/>`__.
  57. - macOS and Windows: You can download precompiled binaries from the
  58. `LLVM website <https://releases.llvm.org/download.html>`__. You may need to add
  59. the path to the binary's folder to your system's ``PATH`` environment
  60. variable to be able to call ``clang-format`` out of the box.
  61. You then have different possibilities to apply clang-format to your changes:
  62. Manual usage
  63. ^^^^^^^^^^^^
  64. You can apply clang-format manually for one or more files with the following
  65. command:
  66. ::
  67. clang-format -i <path/to/file(s)>
  68. - ``-i`` means that the changes should be written directly to the file (by
  69. default clang-format would only output the fixed version to the terminal).
  70. - The path can point to several files, either one after the other or using
  71. wildcards like in a typical Unix shell. Be careful when globbing so that
  72. you don't run clang-format on compiled objects (.o and .a files) that are
  73. in Godot's tree. So better use ``core/*.{cpp,h}`` than ``core/*``.
  74. Pre-commit hook
  75. ^^^^^^^^^^^^^^^
  76. For ease of use, we provide a pre-commit hook for Git that will run
  77. clang-format automatically on all your commits to check them, and let you apply
  78. its changes in the final commit.
  79. This "hook" is a script that can be found in ``misc/hooks``, refer to that
  80. folder's README.md for installation instructions.
  81. If your clang-format is not in the ``PATH``, you may have to edit the
  82. ``pre-commit-clang-format`` to point to the correct binary for it to work.
  83. The hook was tested on Linux and macOS, but should also work in the Git Shell
  84. on Windows.
  85. IDE plugin
  86. ^^^^^^^^^^
  87. Most IDEs or code editors have beautifier plugins that can be configured to run
  88. clang-format automatically, for example, each time you save a file.
  89. Here is a non-exhaustive list of beautifier plugins for some IDEs:
  90. - Qt Creator: `Beautifier plugin <https://doc.qt.io/qtcreator/creator-beautifier.html>`__
  91. - Visual Studio Code: `Clang-Format <https://marketplace.visualstudio.com/items?itemName=xaver.clang-format>`__
  92. - Visual Studio: `Clang Power Tools 2022 <https://marketplace.visualstudio.com/items?itemName=caphyon.ClangPowerTools2022>`__
  93. - vim: `vim-clang-format <https://github.com/rhysd/vim-clang-format>`__
  94. - CLion: Starting from version ``2019.1``, no plugin is required. Instead, enable
  95. `ClangFormat <https://www.jetbrains.com/help/clion/clangformat-as-alternative-formatter.html#clion-support>`__
  96. (Pull requests are welcome to extend this list with tested plugins.)
  97. .. _doc_code_style_guidelines_header_includes:
  98. Header includes
  99. ~~~~~~~~~~~~~~~
  100. When adding new C++ or Objective-C files or including new headers in existing
  101. ones, the following rules should be followed:
  102. - The first lines in the file should be Godot's copyright header and MIT
  103. license, copy-pasted from another file. Make sure to adjust the filename.
  104. - In a ``.h`` header, include guards should be used with the form
  105. ``FILENAME_H``.
  106. - In a ``.cpp`` file (e.g. ``filename.cpp``), the first include should be the
  107. one where the class is declared (e.g. ``#include "filename.h"``), followed by
  108. an empty line for separation.
  109. - Then come headers from Godot's own code base, included in alphabetical order
  110. (enforced by ``clang-format``) with paths relative to the root folder. Those
  111. includes should be done with quotes, e.g. ``#include "core/object.h"``. The
  112. block of Godot header includes should then be followed by an empty line for
  113. separation.
  114. - Finally, third-party headers (either from ``thirdparty`` or from the system's
  115. include paths) come next and should be included with the < and > symbols, e.g.
  116. ``#include <png.h>``. The block of third-party headers should also be followed
  117. by an empty line for separation.
  118. - Godot and third-party headers should be included in the file that requires
  119. them, i.e. in the `.h` header if used in the declarative code or in the `.cpp`
  120. if used only in the imperative code.
  121. Example:
  122. .. code-block:: cpp
  123. /**************************************************************************/
  124. /* my_new_file.h */
  125. /**************************************************************************/
  126. /* This file is part of: */
  127. /* GODOT ENGINE */
  128. /* https://godotengine.org */
  129. /**************************************************************************/
  130. /* Copyright (c) 2014-present Godot Engine contributors (see AUTHORS.md). */
  131. /* Copyright (c) 2007-2014 Juan Linietsky, Ariel Manzur. */
  132. /* */
  133. /* Permission is hereby granted, free of charge, to any person obtaining */
  134. /* a copy of this software and associated documentation files (the */
  135. /* "Software"), to deal in the Software without restriction, including */
  136. /* without limitation the rights to use, copy, modify, merge, publish, */
  137. /* distribute, sublicense, and/or sell copies of the Software, and to */
  138. /* permit persons to whom the Software is furnished to do so, subject to */
  139. /* the following conditions: */
  140. /* */
  141. /* The above copyright notice and this permission notice shall be */
  142. /* included in all copies or substantial portions of the Software. */
  143. /* */
  144. /* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, */
  145. /* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF */
  146. /* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. */
  147. /* IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY */
  148. /* CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, */
  149. /* TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE */
  150. /* SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */
  151. /**************************************************************************/
  152. #ifndef MY_NEW_FILE_H
  153. #define MY_NEW_FILE_H
  154. #include "core/hash_map.h"
  155. #include "core/list.h"
  156. #include "scene/gui/control.h"
  157. #include <png.h>
  158. ...
  159. #endif // MY_NEW_FILE_H
  160. .. code-block:: cpp
  161. /**************************************************************************/
  162. /* my_new_file.cpp */
  163. /**************************************************************************/
  164. /* This file is part of: */
  165. /* GODOT ENGINE */
  166. /* https://godotengine.org */
  167. /**************************************************************************/
  168. /* Copyright (c) 2014-present Godot Engine contributors (see AUTHORS.md). */
  169. /* Copyright (c) 2007-2014 Juan Linietsky, Ariel Manzur. */
  170. /* */
  171. /* Permission is hereby granted, free of charge, to any person obtaining */
  172. /* a copy of this software and associated documentation files (the */
  173. /* "Software"), to deal in the Software without restriction, including */
  174. /* without limitation the rights to use, copy, modify, merge, publish, */
  175. /* distribute, sublicense, and/or sell copies of the Software, and to */
  176. /* permit persons to whom the Software is furnished to do so, subject to */
  177. /* the following conditions: */
  178. /* */
  179. /* The above copyright notice and this permission notice shall be */
  180. /* included in all copies or substantial portions of the Software. */
  181. /* */
  182. /* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, */
  183. /* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF */
  184. /* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. */
  185. /* IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY */
  186. /* CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, */
  187. /* TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE */
  188. /* SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */
  189. /**************************************************************************/
  190. #include "my_new_file.h"
  191. #include "core/math/math_funcs.h"
  192. #include "scene/gui/line_edit.h"
  193. #include <zlib.h>
  194. #include <zstd.h>
  195. Java
  196. ----
  197. Godot's Java code (mostly in ``platform/android``) is also enforced via
  198. ``clang-format``, so see the instructions above to set it up. Keep in mind that
  199. this style guide only applies to code written and maintained by Godot, not
  200. third-party code such as the ``java/src/com/google`` subfolder.
  201. Python
  202. ------
  203. Godot's SCons buildsystem is written in Python, and various scripts included
  204. in the source tree are also using Python.
  205. For those, we follow the `Black style guide <https://github.com/psf/black#the-black-code-style>`__.
  206. Blacken your Python changes using `Black <https://pypi.org/project/black/>`__.
  207. Using black locally
  208. ~~~~~~~~~~~~~~~~~~~
  209. First of all, you will need to install Black. Black requires Python 3.7+ to run.
  210. Installation
  211. ^^^^^^^^^^^^
  212. Here's how to install black:
  213. ::
  214. pip3 install black --user
  215. You then have different possibilities to apply black to your changes:
  216. Manual usage
  217. ^^^^^^^^^^^^
  218. You can apply ``black`` manually to one or more files with the following
  219. command:
  220. ::
  221. black -l 120 <path/to/file(s)>
  222. - ``-l 120`` means that the allowed number of characters per line is 120.
  223. This number was agreed upon by the developers.
  224. - The path can point to several files, either one after the other or using
  225. wildcards like in a typical Unix shell.
  226. Pre-commit hook
  227. ^^^^^^^^^^^^^^^
  228. For ease of use, we provide a pre-commit hook for Git that will run
  229. black automatically on all your commits to check them, and let you apply
  230. its changes in the final commit.
  231. This "hook" is a script which can be found in ``misc/hooks``. Refer to that
  232. folder's ``README.md`` for installation instructions.
  233. Editor integration
  234. ^^^^^^^^^^^^^^^^^^
  235. Many IDEs or code editors have beautifier plugins that can be configured to run
  236. black automatically, for example, each time you save a file. For details, you can
  237. check `Black editor integration <https://github.com/psf/black#editor-integration>`__.
  238. Comment style guide
  239. -------------------
  240. This comment style guide applies to all programming languages used within
  241. Godot's codebase.
  242. - Begin comments with a space character to distinguish them from disabled code.
  243. - Use sentence case for comments. Begin comments with an uppercase character and
  244. always end them with a period.
  245. - Reference variable/function names and values using backticks.
  246. - Wrap comments to ~100 characters.
  247. - You can use ``TODO:``, ``FIXME:``, ``NOTE:``, or ``HACK:`` as admonitions
  248. when needed.
  249. **Example:**
  250. .. code-block:: cpp
  251. // Compute the first 10,000 decimals of Pi.
  252. // FIXME: Don't crash when computing the 1,337th decimal due to `increment`
  253. // being negative.
  254. Don't repeat what the code says in a comment. Explain the *why* rather than *how*.
  255. **Bad:**
  256. .. code-block:: cpp
  257. // Draw loading screen.
  258. draw_load_screen();
  259. You can use Javadoc-style comments above function or macro definitions. It's
  260. recommended to use Javadoc-style comments *only* for methods which are not
  261. exposed to scripting. This is because exposed methods should be documented in
  262. the :ref:`class reference XML <doc_updating_the_class_reference>`
  263. instead.
  264. **Example:**
  265. .. code-block:: cpp
  266. /**
  267. * Returns the number of nodes in the universe.
  268. * This can potentially be a very large number, hence the 64-bit return type.
  269. */
  270. uint64_t Universe::get_node_count() {
  271. // ...
  272. }
  273. For member variables, don't use Javadoc-style comments but use single-line comments instead:
  274. .. code-block:: cpp
  275. class Universe {
  276. // The cached number of nodes in the universe.
  277. // This value may not always be up-to-date with the current number of nodes
  278. // in the universe.
  279. uint64_t node_count_cached = 0;
  280. };