The Godot community is rich and international. Users come from all
around the world. Some of them are young, and many aren’t native English
speakers. That’s why we must all write using a clear and a common
language. For the class reference, the goal is to make it easy to read
for everyone and precise.

Use the direct voice when possible. Take the classes, methods, and
constants you describe as the subject. It’s natural to write using the
passive voice, but it’s harder to read and produces longer sentences.

Game creation and programming aren’t simple, and nothing’s easy to
someone learning to use the API for the first time. Other words in the
list, like just or actual won’t add any info to the sentence.
Don’t use corresponding adverbs either: obviously, simply, basically,
easily, actually, clearly.

Don’t example. The banned words lengthen the description and take
attention away from the most important info:

**TextureRect**
Control frame that **simply** draws an assigned texture. It can stretch or not. It's a **simple** way to **just** show an image in a UI.

Do remove them:

**TextureRect**
[Control] node that displays a texture. The texture can stretch to the node's bounding box or stay in the center. Useful to display sprites in your UIs.

“Simple” never helps. Remember, for other users, anything could be
complex or frustrate them. There’s nothing like a good old it’s simple
to make you cringe. Here’s the old brief description, the first sentence
on the Timer node’s page:

The ‘Oxford comma’ is an optional comma before the word ‘and’ at the end of a list:
We sell books, videos, and magazines.

[…] Not all writers and publishers use it, but it can clarify the meaning of a sentence when the items in a list are not single words:
These items are available in black and white, red and yellow, and blue and green.

Don’t leave the last element of a list without a comma:

Create a KinematicBody2D node, a CollisionShape2D node and a sprite node.

Do add a comma before and or or, for the last
element of a list with more than two elements.

Create a KinematicBody2D node, a CollisionShape2D node, and a sprite node.

The code examples in the documentation should follow a consistent style not to
confuse users. As static type hints are an optional feature of GDScript, we
chose to stick to writing dynamic code. This leads to writing GDScript that is
concise and accessible.

Of course, there are times when using real-world examples is impractical. In
those situations, you should still avoid using names such as my_var,
foo() or my_func() and consider more meaningful names for your examples.

In the class reference, always surround arguments with [code][/code]. In the
documentation and in Godot, it will display like this. When you edit XML
files in the Godot repository, replace existing arguments written like ‘this’ or
`this` with [code]this[/code].

The developers chose some specific words to refer to areas of the
interface. They’re used in the sources, in the documentation, and you
should always use them instead of synonyms, so the users know what
you’re talking about.

Overview of the interface and common vocabulary

In the top left corner of the editor lie the mainmenus. In the
center, the buttons change the workspace. And together the buttons
in the top right are the playtestbuttons. The area in the center,
that displays the 2D or the 3D space, is the viewport. At its top,
you find a list of tools inside the toolbar.

The tabs or dockable panels on either side of the viewport are
docks. You have the FileSystemdock, the Scenedock that
contains your scene tree, the Importdock, the Nodedock, and
the Inspector or Inspectordock. With the default layout you may
call the tabbed docks tabs: the Scenetab, the Nodetab…

The Animation, Debugger, etc. at the bottom of the viewport are
panels. Together they make up the bottompanels.

Foldable areas of the Inspector are sections. The node’s parent
class names, which you can’t fold, are Classes e.g. the
KinematicBody2Dclass. And individual lines with key-value pairs are
properties. E.g. position or modulatecolor are both
properties.

Keyboard and mouse shortcuts should make use of the :kbd: tag, which allows
shortcuts to stand out from the rest of the text and inline code. Use the
compact form for modifier keys (Ctrl/Cmd) instead of their spelled
out form (Control/Command). For combinations, use the + symbol
with a space on either side of the symbol.

Make sure to mention shortcuts that differ on macOS compared to other platforms.
On macOS, Cmd often replaces Ctrl in keyboard shortcuts.

Try to integrate the shortcut into sentences the best you can. Here are some
examples with the :kbd: tag left as-is for better visibility:

Press :kbd:`Ctrl+Alt+T` to toggle the panel (:kbd:`Cmd+Alt+T` on macOS).

Press :kbd:`Space` and hold the left mouse button to pan in the 2D editor.

A significant part of the documentation is images, and there are several
important guidelines to follow.

First, you should always be using the default editor theme and text when taking
screenshots.

To improve the appearance of 3D screenshots, use 4× MSAA, enable anisotropic
filtering on the project’s textures, and set the anisotropic filter quality to
16× in Project Settings.

Screenshot sizes should not exceed 1920×1080 to ensure fast loading on slower
connections.

When you need to highlight an area of the editor to show something, like a
button or option, use a 2 pixel thick outline without a bevel.

Before you add or replace any images in the documentation, they should be run
through a PNG compressor to save size. The built in lossless compressor in
programs like Krita or Photoshop should be enough. For heavier images, also look
into using a lossy compressor, such as pngquant where
almost no image quality is lost during compression.