Update recommendation on #pragma once in C++ usage guidelines

contributing/development/cpp_usage_guidelines.rst

@@ -45,11 +45,11 @@ variables and ``nullptr`` is encouraged when possible. Still, try to keep your
 use of modern C++ features conservative. Their use needs to serve a real
 purpose, such as improving code readability or performance.
 
-Standard Template Library
-~~~~~~~~~~~~~~~~~~~~~~~~~
+Standard Template Library containers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 We don't allow using the `STL <https://en.wikipedia.org/wiki/Standard_Template_Library>`__
-as Godot provides its own data types (among other things).
+containers as Godot provides its own data types (among other things).
 See :ref:`doc_faq_why_not_stl` for more information.
 
 This means that pull requests should **not** use ``std::string``,
@@ -94,11 +94,47 @@ Lambdas should be used conservatively when they make code effectively faster or
 simpler, and do not impede readability. Please ask before using lambdas in a
 pull request.
 
-``#pragma once`` directive
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+Traditional include guards
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-To follow the existing style, please use standard ``#ifdef``-based include
-guards instead of ``#pragma once`` in new files.
+To follow the existing style, please use ``#pragma once``
+instead of traditional header guards (``#ifndef MY_CLASS_H ...``)
+in new files:
+
+**Good**:
+
+.. rst-class:: code-example-good
+
+.. code-block:: cpp
+
+    #pragma once
+
+    #include "core/object/ref_counted.h"
+
+    class MyClass : public RefCounted {
+        GDCLASS(MyClass, RefCounted);
+
+        // ...
+    };
+
+**Bad**:
+
+.. rst-class:: code-example-bad
+
+.. code-block:: cpp
+
+    #ifndef MY_CLASS_H
+    #define MY_CLASS_H
+
+    #include "core/object/ref_counted.h"
+
+    class MyClass : public RefCounted {
+        GDCLASS(MyClass, RefCounted);
+
+        // ...
+    };
+
+    #endif
 
 ``try``-``catch`` blocks
 ~~~~~~~~~~~~~~~~~~~~~~~~

tutorials/scripting/gdscript/gdscript_styleguide.rst

@@ -801,19 +801,19 @@ We suggest to organize GDScript code this way:
     13. remaining static methods
     14. overridden built-in virtual methods:
         1. _init()
-        2. _enter_tree() 
+        2. _enter_tree()
         3. _ready()
         4. _process()
         5. _physics_process()
         6. remaining virtual methods
     15. overridden custom methods
-    16. remaining methods
+e    16. remaining methods
     17. subclasses
 
 And put the class methods and variables in the following order depending on their access modifiers:
 
 ::
-   
+
     1. public
     2. private