cpp_usage_guidelines.rst 3.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107
  1. .. _doc_cpp_usage_guidelines:
  2. C++ usage guidelines
  3. ====================
  4. Rationale
  5. ---------
  6. Since Godot 4.0, the C++ standard used throughout the codebase is a subset of
  7. **C++17**. While modern C++ brings a lot of opportunities to write faster, more
  8. readable code, we chose to restrict our usage of C++ to a subset for a few
  9. reasons:
  10. - It makes it easier to review code in online editors. This is because engine
  11. contributors don't always have access to a full-featured IDE while reviewing
  12. code.
  13. - It makes the code easier to grasp for beginner contributors (who may not be
  14. professional C++ programmers). Godot's codebase is known to be easy to learn
  15. from, and we'd like to keep it that way.
  16. To get your pull request merged, it needs to follow the C++ usage guidelines
  17. outlined here. Of course, you can use features not allowed here in your own C++
  18. modules or GDExtensions.
  19. .. note::
  20. Prior to Godot 4.0, the C++ standard used throughout the codebase was C++03,
  21. with a handful of C++14 extensions. If you are contributing a pull request
  22. to the `3.x` branch rather than `master`, your code can't use C++17 features.
  23. Instead, your code must be able to be built with a C++14 compiler.
  24. The guidelines below don't apply to third-party dependencies, although we
  25. generally favor small libraries instead of larger solutions. See also
  26. :ref:`doc_best_practices_for_engine_contributors`.
  27. .. seealso::
  28. See :ref:`doc_code_style_guidelines` for formatting guidelines.
  29. Disallowed features
  30. -------------------
  31. **Any feature not listed below is allowed.** Using features like ``constexpr``
  32. variables and ``nullptr`` is encouraged when possible. Still, try to keep your
  33. use of modern C++ features conservative. Their use needs to serve a real
  34. purpose, such as improving code readability or performance.
  35. Standard Template Library
  36. ^^^^^^^^^^^^^^^^^^^^^^^^^
  37. We don't allow using the `STL <https://en.wikipedia.org/wiki/Standard_Template_Library>`__
  38. as Godot provides its own data types (among other things).
  39. See :ref:`doc_faq_why_not_stl` for more information.
  40. This means that pull requests should **not** use ``std::string``,
  41. ``std::vector`` and the like. Instead, use Godot's datatypes as described below:
  42. - Use ``String`` instead of ``std::string``.
  43. - Use ``Vector`` instead of ``std::vector``. In some cases, ``LocalVector``
  44. can be used as an alternative (ask core developers first).
  45. - Use ``Array`` instead of ``std::array``.
  46. .. note::
  47. Godot also has a List datatype (which is a linked list). While List is already used
  48. in the codebase, it typically performs worse than other datatypes like Vector
  49. and Array. Therefore, List should be avoided in new code unless necessary.
  50. ``auto`` keyword
  51. ^^^^^^^^^^^^^^^^
  52. Please don't use the ``auto`` keyword for type inference. While it can avoid
  53. repetition, it can also lead to confusing code:
  54. .. code-block:: cpp
  55. // Not so confusing...
  56. auto button = memnew(Button);
  57. // ...but what about this?
  58. auto result = EditorNode::get_singleton()->get_complex_result();
  59. Keep in mind hover documentation often isn't readily available for pull request
  60. reviewers. Most of the time, reviewers will use GitHub's online viewer to review
  61. pull requests.
  62. We chose to forbid ``auto`` instead of allowing it on a case-by-case basis to
  63. avoid having to decide on difficult edge cases. Thank you for your understanding.
  64. Lambdas
  65. ^^^^^^^
  66. Lambdas should be used conservatively when they make code effectively faster or
  67. simpler, and do not impede readability. Please ask before using lambdas in a
  68. pull request.
  69. ``#pragma once`` directive
  70. ^^^^^^^^^^^^^^^^^^^^^^^^^^
  71. To follow the existing style, please use standard ``#ifdef``-based include
  72. guards instead of ``#pragma once`` in new files.
  73. .. seealso::
  74. See :ref:`doc_code_style_guidelines_header_includes` for guidelines on sorting
  75. includes in C++ and Objective-C files.